DEV Community: Shayan

Stop asking "would you use this?" (here's what to do instead)

Shayan — Tue, 09 Dec 2025 19:10:05 +0000

I've built things that nobody used. More than once. And looking back, the frustrating part is that I thought I had validated the idea before building. I asked people if they'd use it, they said yes, and then when I launched they didn't. It took me a while to understand why this keeps happening, and it comes down to one thing: hypothetical questions get hypothetical answers.

When you ask someone "would you use this?" you're asking them to predict their own future behavior. People are bad at this. They're also nice, and they don't want to crush your enthusiasm, so they say yes. They genuinely believe it too. But there's a massive gap between "yeah I'd probably use that" and actually signing up, learning how it works, and making it part of their workflow.

Here's what I do instead.

1. Ask about their past, not their future

Instead of asking people if they'd use your thing, ask them what they're already doing to solve the problem you're addressing. This tells you way more. This is the core idea behind The Mom Test by Rob Fitzpatrick, which every founder should read. But knowing the concept and actually applying it are different things.

If you're thinking about building a tool to help people track their habits, don't ask "would you use a habit tracking app?" Ask "what did you do the last time you tried to build a new habit? What tools or methods did you use? Why did you stop using them?"

Now you're getting real information. You're learning what they actually tried, what worked, what didn't, and where they gave up. This is gold compared to a hypothetical yes or no.

The same applies if you're building a developer tool, a SaaS product, or anything else. Find people who have the problem and ask them to walk you through how they currently deal with it. If they can't describe their current workaround, they probably don't have the problem badly enough to pay for a solution.

2. Look for people already using bad solutions

One of the strongest validation signals I've found is discovering that people are already solving your problem with something that wasn't designed for it. Spreadsheets are the classic example. If you find people tracking customer feedback in Google Sheets, manually copying data between tools, or building janky internal scripts to automate something, that's real demand.

These people have already proven they care enough about the problem to spend time on a workaround. They're not giving you a hypothetical yes, they're showing you with their behavior that this problem matters to them. Your job is to give them something better than their spreadsheet.

When I was building UserJot, I noticed a lot of indie hackers and small teams tracking feature requests in Notion tables, Trello boards, or just their email inbox. The problem was that users couldn't see any of it. They'd submit feedback and have no idea if anyone read it, leading to duplicate requests and the feeling that their input went into a black hole. People cared about user feedback enough to set up some system, but the systems weren't solving the actual problem. That told me there was demand for something purpose-built.

3. Watch for repeated complaints

Another signal I trust is when people complain about the same problem repeatedly in communities you're part of. Not one tweet, but a pattern. If you keep seeing developers complain about a specific friction point, or founders asking how to solve the same thing in different Slack groups, that's validation.

The key word is repeated. One person complaining once doesn't mean much. But if you see the same frustration come up again and again across different people, you're onto something real. I keep a running list of complaints I see in communities I'm part of. Patterns emerge over time.

The caveat here is that complaining doesn't always mean people will pay for a solution. Sometimes people complain about things they wouldn't actually spend money to fix. So the complaints are a starting point, not proof. But they're a much better starting point than asking "would you use this?" and getting polite yeses.

4. Make people put something on the line

The reason hypothetical validation fails is there's no cost to saying yes. Real validation requires some form of commitment.

The classic version is asking for money. Can you get someone to pre-order? Can you charge $10 for early access? Even a small amount separates people who are genuinely interested from people who are being nice. If you ask 50 people if they'd pay for your tool and all 50 say yes, but then you ask those same 50 people to pay $20 for early access and only 2 do, you've learned something important.

Money isn't the only option though. Time works too. If you set up a landing page and someone gives you their email and then actually opens your emails and responds to them, that's a real signal. If someone spends 30 minutes on a call with you to talk about their problems, that's a real signal. The point is that some form of friction separates real interest from polite interest.

Waitlists can be misleading here because email signups are pretty low-friction. Thousands of people on a waitlist doesn't mean thousands of people will use your product. I've seen products with huge waitlists launch to crickets because the signups were just casual curiosity, not real demand.

5. Pay attention to what users do after launch

Validation doesn't stop when you ship. In some ways, the most useful validation happens after you have real users because now you can watch behavior instead of asking questions.

The difference between what users say they want and what they actually use is huge. Someone might request a feature, you build it, and they never touch it. Someone else might never request anything but use your product every single day. Behavior tells the truth.

I track a few things to understand real demand after launch. First, do people come back? If someone signs up and then never logs in again, they didn't have the problem badly enough. Second, do people tell others about it? Organic referrals are a strong signal that you're solving a real problem. Third, what features get the most engagement versus what features people ask for? And here's one people forget: do users care when you actually ship something? If you publish a changelog update and nobody reacts or clicks through, that feature might not have been as important as they said it was.

This is where structured feedback becomes useful. I think feedback loops are important enough that I built my own tool for it. With UserJot, users can submit ideas and vote on each other's requests, so I can see what actually has demand based on engagement, not just based on whoever emailed me most recently. When multiple people upvote the same feature request, that's a stronger signal than one person mentioning it once. There are also open source options like Fider if you want to self-host.

6. Accept that you can't fully validate without building

Here's the uncomfortable truth: you can never be 100% certain there's demand until you build something and see if people use it. All the validation tactics above reduce risk, but they don't eliminate it. At some point you have to ship.

The goal isn't perfect validation. The goal is to derisk enough that you're not spending six months building something nobody wants. If you've found people using workarounds, heard repeated complaints, and gotten a few people to commit money or serious time, you've validated enough to build a first version. It doesn't have to be the full product. Build the smallest thing that solves the core problem and see if people actually use it.

I used to spend way too long in "validation mode" when really I was just procrastinating because building is scary and rejection is uncomfortable. Now I try to validate quickly and build small. If I'm wrong, I want to find out in weeks, not months.

Quick reference: validation signals ranked

Weak signals (don't trust these alone):

Friends and family saying it's a good idea
Positive responses to "would you use this?"
Likes and upvotes on a concept post
Large waitlist with low-friction signup

Stronger signals:

People describing their current janky workarounds
Repeated complaints about the same problem in communities
Someone giving you their email and then actually engaging with your emails
People spending real time on a call to discuss their problems

Strong signals:

Someone paying money, even a small amount
Beta users who come back without being prompted
Users referring others organically
Multiple users requesting the same thing with engagement behind it

The difference between validation and reality is behavior. Watch what people do, not what they say they'd do. If someone is already spending time or money to solve the problem you're addressing, that's real. If they're just nodding along to your pitch, that's polite interest, and polite interest doesn't convert to users.

I'm building UserJot to solve the feedback loop problem for my own products. If you're tired of tracking feature requests in spreadsheets, give it a try. There's a free tier.

What most devs forget when launching (and regret later)

Shayan — Tue, 02 Dec 2025 22:46:17 +0000

Most developers spend weeks or months building something, then rush through the launch in a single afternoon. They tweet about it, post on a few forums, and then wonder why nobody shows up. The product is solid, but everything around it is an afterthought.

I've done this myself. I've also watched dozens of other developers make the same mistakes. Here's what gets forgotten most often.

A way for users to tell you what's broken

You launch. Something breaks. A user hits the bug, gets frustrated, and leaves. You have no idea this happened because there's no error tracking, no feedback widget, nothing. You find out three weeks later when someone finally emails you.

Set up error monitoring before you launch. Sentry takes maybe 20 minutes to integrate and will save you from silent failures. But error tracking only catches crashes. It doesn't catch confusing UI, missing features, or workflows that just don't make sense to real people.

You need a way for users to actually tell you what's wrong or what they wish existed. I think this is so important that I built my own tool for it called UserJot. But even a simple feedback form is better than nothing. The point is giving users a voice that isn't your personal email inbox.

Analytics that answer real questions

Everyone sets up Google Analytics and thinks they're done. Then they realize GA tells you almost nothing useful about a web app. You know people visited. You don't know what they did.

Set up something like PostHog, Mixpanel, or Amplitude. Track the specific actions that matter for your product. Did they complete onboarding? Did they create their first project? Did they invite a teammate? These are the numbers that tell you if your product is working, not pageviews.

The developers who skip this end up making decisions based on gut feeling and a handful of anecdotes from users who happened to email them. That's not a strategy.

A landing page that actually explains the product

Developers love building features. They hate writing copy. So you end up with a landing page that says something vague like "the modern platform for teams" with a screenshot that doesn't explain anything.

Your landing page needs to answer one question in about five seconds: what does this thing do and why would I want it? A confused visitor isn't going to dig through your docs to figure it out. They'll just leave.

Write a headline that a stranger could understand. Show the product in action, not just abstract UI mockups. Include at least one testimonial, even if it's from a beta user. Make the signup button obvious. This isn't complicated, but it's easy to skip when you're excited to ship.

A way to contact users after they sign up

A lot of developers treat email like spam and refuse to collect it. Or they collect emails but never actually send anything. Then when they ship a major update or fix a critical bug, they have no way to tell their users.

At minimum, you need transactional emails working. Password resets, account confirmations, that kind of thing. But you should also have a way to announce updates. This could be a changelog, a newsletter, or both.

The developers who do this well end up with users who stick around because they see the product improving. The developers who skip it have users who sign up, forget about the product, and never come back.

A plan for what happens after launch day

Launch day is a spike. Maybe you get on Hacker News or Product Hunt and traffic goes crazy for 24 hours. Then it's over and you're back to zero.

The developers who build real traction have a plan for the weeks after launch. They have content scheduled. They have communities they're active in. They have a list of people to reach out to. They treat launch as the beginning of marketing, not the end.

If your entire strategy is "launch and hope it goes viral," you're going to be disappointed. Viral moments are rare and unpredictable. Consistent effort over months is what actually works for most products.

The pattern I see over and over

The developers who struggle aren't building bad products. They're building good products and then treating everything else as optional. Marketing is optional. Feedback collection is optional. Analytics are optional. User communication is optional.

Then they wonder why nobody is signing up.

The product is maybe 30% of the work. The other 70% is everything around it: positioning, distribution, user communication, feedback loops, iteration based on real data. Skip that and you're just building in a vacuum.

If any of this sounds familiar, you're not alone. Most developers learn this the hard way. The good news is that none of it is particularly difficult to fix. It just requires actually doing it before you launch instead of promising yourself you'll add it later.

You won't add it later. Add it now.

How I decide when an app is ready to launch

Shayan — Mon, 01 Dec 2025 18:32:27 +0000

There's no perfect moment to launch. I've shipped things too early and watched users bounce off broken flows. I've also waited too long, polishing features nobody asked for while the motivation slowly drained out of me. After launching a few products, I've landed on a simple framework for deciding when something is ready.

The core feature has to work

This sounds obvious, but it's easy to get wrong. Your app probably does multiple things, and you need to be honest about which one is the core feature. That's the one thing that has to work reliably before you launch.

For a note-taking app, that's creating and saving notes. For a feedback tool, that's submitting and viewing feedback. For an invoicing app, that's creating and sending an invoice. Everything else is secondary.

I ask myself one question: if a user signs up and tries to do the main thing, will it work? Not perfectly, not beautifully, but will it actually work? If the answer is yes, that box is checked.

Users can sign up and log back in

Authentication sounds basic, but I've launched things where edge cases in the auth flow caused real problems. Password reset didn't work. OAuth broke on certain browsers. Session expired too quickly.

Before I launch anything, I create a fresh account with a new email, go through the full sign up flow, log out, and log back in. I also test password reset. These paths get used immediately and failing here makes your product look broken even if everything else works.

I've used it myself for at least a few days

I don't launch things I haven't used. Not just tested, but actually used for real tasks over multiple days. This is where you find the friction that quick testing misses.

When I was building my feedback tool, I used it to collect feedback on itself during development. That sounds circular, but it revealed problems I never would have found otherwise. Features I thought were intuitive turned out to be confusing. Things I thought were fast turned out to feel slow when you're doing them repeatedly.

A few days of real usage teaches you more than weeks of staring at your code.

At least one other person has tried it

You're too close to your own product to see it clearly. You know where everything is. You know the workarounds. You fill in gaps mentally without realizing it.

I always get at least one other person to try the product before launching. Not for detailed feedback, just to watch where they get stuck. The first time someone else uses your app is humbling. They'll click things you didn't expect, miss things you thought were obvious, and abandon flows you thought were straightforward.

You don't need a formal beta program. Just one friend or colleague willing to spend 10 minutes poking around. Their confusion will show you what needs fixing before you put it in front of strangers.

I've decided what I'm not building yet

Scope creep kills launches. There's always one more feature that feels essential, one more edge case that needs handling, one more improvement that would make everything better.

Before I launch, I make a list of everything I'm explicitly not building yet. I write it down. This sounds unnecessary, but it helps me stop second-guessing. When I think "maybe I should add X before launching," I can check the list and remember that I already decided to ship without it.

The things on this list aren't bad ideas. They're just not launch blockers. They can come later, informed by real feedback from real users.

I have a way to hear what's wrong

Launching without a feedback channel is flying blind. Users will have problems, find bugs, and want features. If you don't give them an easy way to tell you, they'll just leave and you'll never know why.

I think collecting feedback is so important that I built my own tool for it called UserJot. But you don't need anything fancy. A feedback form, a dedicated email address, or even a link to a simple survey works. The point is that users can reach you easily and you have a place to collect what they tell you.

This also takes pressure off the launch. You don't need to get everything right because you have a system for learning what to fix next.

The things that don't matter yet

Here's what I've learned to ignore when deciding whether to launch:

Perfect design. Good enough is good enough. You can improve the design after you know people actually want to use the thing.

Full feature parity with competitors. You're not going to win by having more features on day one. You're going to win by doing one thing well and improving based on feedback.

Documentation. A few tooltips and a basic help page are enough. If users constantly need documentation, your UX has bigger problems.

Scale. Unless you have reason to expect massive traffic on day one, don't worry about scale. Most products launch to a handful of users. You can optimize later when you have real load.

Edge cases. Some edge cases matter, but most don't. The ones that matter will become obvious quickly when real users hit them.

The actual decision

After all of this, the decision usually isn't that hard. I look at my checklist:

Does the core feature work?
Can users sign up and log back in?
Have I used it myself for a few days?
Has at least one other person tried it?
Do I have a clear list of what I'm not building yet?
Do I have a way to hear what's wrong?

If the answer to all of these is yes, I launch. If I'm still hesitating after that, I remind myself that the hesitation is usually fear, not a real problem. The feedback I'll get from launching will be more valuable than anything I'd learn by waiting.

The goal isn't to launch something perfect. The goal is to launch something real and start learning from the people who use it.

My checklist before launching any app

Shayan — Wed, 26 Nov 2025 17:44:34 +0000

I've launched a few products at this point, and I've made enough mistakes to know what actually matters versus what's just procrastination disguised as preparation. Here's the checklist I run through before every launch.

1. Set up analytics before you have users

I know it feels pointless when you have zero users, but in a few months you're going to wish you had data from day one. Setting up analytics takes maybe 30 minutes and it means you can actually see what users do in your app, not what you think they do.

I use PostHog for this. It's free for most early stage products, and you can track events, see session recordings, and run basic funnels. Mixpanel and Amplitude work too. At minimum you want to track sign ups, key activation events, and upgrades if you have paid plans. You can add more later, but get the basics in before launch.

2. Set up a feedback board

I skipped this on my earlier projects and regretted it every time. A feedback board is where users can submit feature requests, report bugs, and upvote each other's ideas so you can see what's actually important to them.

Without one, you get feature requests scattered across email, Twitter DMs, support chat, and random Slack messages. You lose track and end up building what you remember rather than what matters. With a feedback board, the most requested stuff floats to the top and you can see exactly how many people want something. When you ship it, you can notify everyone who asked, which is huge for retention.

I think this step is so important that I actually built my own tool for it called UserJot. There are also open source options like Fider if you want to self-host. Whatever you pick, make it accessible from inside your app. The easier it is to submit feedback, the more you'll get, and more feedback early on means fewer bad decisions later.

3. Set up error monitoring

Your app will break, and you want to know about errors before your users tell you, or worse, before they just leave and never come back.

Sentry and Axiom are good options for this. They catch exceptions, show you the stack trace, and tells you how many users are affected. The free tier is enough for most products at this stage. Set it up for both frontend and backend so when something breaks, you have context about what page they were on, what they were trying to do, and what browser they're using. Takes maybe 20 minutes and will save you hours of debugging later.

4. Set up transactional emails

You need to send emails for welcome messages, password resets, receipts, and notifications. Don't try to send from your own server because you'll end up in spam folders and waste days debugging deliverability issues.

I use SES because the API is clean and it's very powerful. Postmark is another solid option. At minimum you want a welcome email for sign ups, password reset, and receipts for purchases if you're charging. You can get fancy with drip sequences later, but for launch just get the basics working.

5. Get your landing page right

I'm not saying spend three weeks on it, but spend more than an afternoon. Your landing page has one job, which is convincing someone to try your product, and everything on the page should support that.

You want a clear headline that explains what it does in one sentence, a screenshot or demo that shows the actual product, some social proof even if it's just one testimonial from a beta user, and a clear call to action with one obvious button. Things like fancy animations, beautiful illustrations, and ten different pricing tiers can wait.

I use Astro for building static landing pages. It's very simple, powerful and can be easily deployed anywhere. A simple test is to show your landing page to someone who doesn't know what you're building and see if they can explain what it does in 10 seconds. If they can't, simplify.

6. Test the critical paths

Before you announce to the world, actually use your product like a real user would. Go through the sign up flow with a new email instead of your test account, try the main thing your product does, go through the payment flow if you have one, test password reset, and sign out and sign back in.

I can't count how many times I've launched something and the sign-up flow was broken in some edge case. If you can, get 2-3 people to test it too because fresh eyes catch things you've gone blind to.

7. Prepare your launch channels

Figure out where you're going to announce before launch day, not during. For most dev tools and products, the usual options are Twitter, Hacker News if it's technical enough, Product Hunt, relevant subreddits, Indie Hackers, and your email list if you have one.

You don't need to hit all of these. Pick 2-3 that make sense for your audience and write your launch posts in advance. You don't want to be crafting tweets while also fixing bugs on launch day.

8. Have a way to talk to users

On launch day, people will have questions, find bugs, and give feedback. You need a way to respond quickly. Email works, chat widgets like Intercom or Crisp work, and Discord servers work if you want to build community.

I usually start with email and my feedback board. The key is to respond fast, especially early on. People remember when the founder replies in 5 minutes and it builds loyalty that's hard to get otherwise.

9. Ship before it's perfect

Your app isn't ready and it never will be. There's always one more feature to add, one more bug to fix, one more design tweak that would make it better. Ship anyway.

The feedback you get from real users in week one will be worth more than the features you'd build in month three. If your core feature works and people can sign up, you're ready enough.

The checklist

[ ] Analytics tracking key events
[ ] Feedback board accessible from the app
[ ] Error monitoring on frontend and backend
[ ] Transactional emails working
[ ] Landing page explains what you do clearly
[ ] Critical paths tested with a fresh account
[ ] Launch posts written for 2-3 channels
[ ] Way to respond to users ready

That's it. The launch itself matters less than you think. What matters is what you do in the weeks after, which is talking to users, fixing what's broken, and building what they actually need. The checklist just makes sure you're not starting from zero when the feedback starts rolling in.

Building Features Won't Save Your Product (But This Will)

Shayan — Thu, 23 Oct 2025 14:28:56 +0000

Here's an unpopular opinion: most founders use feature development as a distraction from the hard work of marketing.

I've watched it happen over and over. A founder launches a product, gets a few users, then immediately retreats into "just one more sprint." They convince themselves that the next feature will unlock growth. It never does. The cycle continues until they burn out, bloat their product, or run out of runway.

The psychology is simple: building features feels productive. Marketing feels uncomfortable, uncertain, maybe even sleazy. So you hide in your IDE and tell yourself you're "adding value."

Here's what you need to hear instead.

The Real Reason You Keep Building Features

You're avoiding the conversation you need to have with your market. Building is safe. You control the scope, the timeline, the outcome. Marketing requires you to get rejected, hear "no," and face the possibility that your product just isn't compelling enough.

So you build. And build. And build.

Here's the brutal truth: adding features is the easiest way to feel busy while avoiding revenue. You can spend weeks on a feature that three people asked for and tell yourself you're "customer-driven." Meanwhile, hundreds of potential customers have no idea you exist.

Why More Features ≠ More Value

Most founders believe more features = more value. It's intuitive. It's also completely wrong.

Value isn't measured by feature count. It's measured by the hours you save your customer. If your product saves someone 10 hours a week, that's your value proposition. Whether you do it with 5 features or 50 doesn't matter to them. They care about outcomes, not capabilities.

I learned this the hard way. I built a SaaS with 47 features. It did everything. User engagement was terrible because nobody could figure out what it actually did. My messaging was vague ("All-in-one solution!") because I was trying to sell every feature instead of a single, clear outcome.

The Math That Actually Matters

Here's the only equation that matters for your SaaS:

Value = Hours Saved × Hourly Rate

If your product saves a $50/hour worker 5 hours per week, you're delivering $250/week in value. That's $1,000/month. You can charge $99/month and it's a no-brainer.

But here's the catch: you can't save anyone's time if they don't know you exist. You could have the most elegant, powerful, life-changing product in your category. If your messaging is unclear and nobody's heard of you, your value is zero.

What Happened When I Cut 44 Features

I stripped my product down to three core workflows. Not because the other 44 features were bad. They worked fine. But they diluted my message. Every additional feature made it harder to explain what problem I actually solved.

Once I simplified, my messaging became crystal clear: "Save 10 hours a week on customer feedback." That's it. No feature lists. No "all-in-one" nonsense. Just a single, measurable outcome.

Revenue doubled in 90 days. Not because I built something new. Because I could finally explain what I'd already built.

How to Know Which Features Actually Matter

Okay, so if you're not supposed to build more features, how do you know what to build next? Here's what I should've done from day one: stop guessing and start asking.

Build your MVP. Put it in front of real users. Then religiously collect their feedback. Not informal Slack messages. Not "let me know if you have any issues" emails. A systematic, public feedback board where users can submit requests, upvote each other's ideas, and discuss what they actually need.

This is where something like UserJot comes in. It's a feedback board where your users leave feature requests, vote on what matters most to them, and help you see patterns you'd never spot on your own.

Here's what happens when you do this right:

You see which requests show up repeatedly across different users
You stop building features three people asked for in private DMs
You discover the gap between what you think users need and what they're actually asking for
You let demand guide your roadmap instead of assumptions

The votes and comments become your priority queue. If 50 users are asking for the same thing and 2 users are asking for something else, the math is obvious.

This approach saved me from building another 20 features nobody wanted. I thought users needed advanced reporting. Turns out they just wanted better email notifications. I would've spent a month on the wrong thing if I hadn't asked first.

How to Stop Building and Start Selling

Here's your action plan:

1. Identify your core value proposition in one sentence

If you can't explain the hours saved or the specific problem solved in 10 words or less, your messaging is broken. Fix this before you write another line of code.

2. Audit your feature list

Go through every feature and ask: "Does this directly contribute to my core value proposition?" If not, deprecate it or hide it. Complexity kills conversions.

3. Write your marketing copy before your next feature

Seriously. Open a doc and write the landing page for your next planned feature. If you can't make it sound compelling in 3 sentences, don't build it.

4. Set a build/marketing ratio

For every hour you spend coding, spend an equal hour on marketing. Write content. Reach out to potential users. Explain what you've already built. If this feels uncomfortable, good. That's the work you've been avoiding.

5. Track messaging clarity, not feature count

Your success metric isn't "shipped 12 features this quarter." It's "100 people understood our value prop well enough to sign up." Measure what matters.

The Uncomfortable Truth

Marketing is harder than building. Building lets you hide behind your screen and control every variable. Marketing forces you to put your work in front of people who might not care. It requires you to get rejected, iterate on messaging, and do the uncomfortable work of selling.

That's why most technical founders avoid it.

But here's the thing: your product doesn't need more features. It needs more people to understand the features it already has. It needs clear, confident messaging that promises a specific outcome and delivers on it.

Stop building. Start explaining.

If you can't sell what you've already built, adding more features won't help. Fix your messaging first. Then, and only then, consider building something new.

What's the one outcome your product delivers?

If you can't answer that in 10 words, that's your homework. Not your next feature sprint.

Why Your SaaS Needs a Feedback Board (And How It Cuts Churn)

Shayan — Tue, 14 Oct 2025 19:08:28 +0000

You're building a SaaS product and making decisions based on gut feeling. You think you know what users need, so you ship features that seem smart. You read support tickets, glance at analytics, maybe run a survey. Then you build what feels right.

The result is you end up with two problems. First, you bloat your product with features nobody asked for. Second, you ignore what users actually want because you're too busy building what you assumed they needed. Six months later, users start churning. You're left wondering what went wrong.

Here's what I learned: guessing what users want is expensive. Giving them a place to tell you is actually how you reduce churn. That place is a feedback board.

The Black Hole Problem

Most SaaS products collect feedback through support tickets or email. Users send a message and… nothing. No visibility into whether you read it, no idea if you're building it, no sense that their voice matters.

This creates a one-way street. Users shout into the void and eventually stop shouting altogether.

A feedback board flips this. It's transparent, visible, and ongoing. Users submit ideas, see what others want, vote on features that matter to them, and watch as you actually build the stuff they asked for.

Why Feedback Boards Increase Engagement

Here's the thing about feedback boards. They work because of visibility and social proof.

When users see an active board with real responses from your team, they trust you're listening. When they see others submitting ideas and getting replies, they're more likely to participate. When they can track their submission from "Under consideration" to "Planned" to "Completed," they feel invested.

It's not a black hole. It's a conversation. And conversations keep people around.

Stop Assuming, Start Validating

I used to prioritize features based on gut feeling. "This would be cool" or "Users probably need this." Half the time I was wrong.

Feedback boards give you real validation. You see what people actually want, not what you assume they want. You see how many people want it through upvotes. You understand why they want it through comments and discussions.

This changes your entire product strategy. Instead of shipping features that get 10% adoption, you're building what 80% of your users are asking for. That's not just efficient—it's how you reduce churn.

When users see you build the exact features they voted for, they stick around. When they see you ignore them and ship random stuff, they leave.

Building in Public Without the Chaos

"Building in public" sounds great until you're posting daily updates on Twitter and nobody cares. A feedback board is building in public that actually works. You're not performing for an algorithm—you're showing your users what you're working on.

Here's how it plays out:

User submits feedback → You change status to "Planned" → They get notified
You start building → Change status to "In progress" → They get another notification
You ship it → Mark it "Completed" and publish a changelog → One more notification

Each touchpoint reminds them you're listening. Each status update reinforces that their input shaped your product. That's retention gold.

Transparency Builds Trust (And Trust Reduces Churn)

Users don't expect you to build every feature they suggest. They expect honesty.

When you mark something as "Under consideration," you're saying "We hear you, we're thinking about it." When you mark it "Planned," you're committing. When you mark something as "Won't implement," you're being real about your priorities.

That transparency builds trust. Users know where they stand. They see you're thoughtful about what you build and why.

Contrast this with the typical SaaS experience: silence. Users request features and hear nothing. Months go by. They assume you don't care. They churn.

A feedback board eliminates that silence.

The Product-Led Growth Angle

Here's a bonus most people miss: feedback boards drive product-led growth.

When you have a public feedback board, users share it. They send the link to teammates, post it in Slack channels, mention it in communities. "Hey, this product actually listens—check out their roadmap."

Your feedback board becomes social proof. New visitors see active discussions, real responses from your team, and a clear roadmap. That's more convincing than any landing page copy.

Plus, engaged users refer more users. When people feel heard, they become advocates. They tell others about your product because they're genuinely invested in seeing it succeed.

What Good Feedback Boards Actually Do

Let me break down the mechanics that make this work:

Upvoting and prioritization: Users vote on what matters most. You build based on demand, not guesswork.

Comments and discussions: Users explain why they need a feature. You understand their workflow and build better solutions.

Status updates: Users track progress from submission to completion. Each update is a retention touchpoint.

Public roadmaps: Users see what's coming next. They're less likely to churn when they know their requested feature is "In progress."

Changelogs: When you ship, users get notified automatically. They see you actually delivered on what they asked for.

This entire loop (submit, upvote, discuss, track, celebrate) keeps users engaged with your product even when they're not using it.

What This Looks Like in Practice

I've seen this work firsthand. A user submits a feature request. Ten others upvote it and add comments explaining their use case. You mark it "Planned" and everyone who voted gets an email. Two weeks later, you move it to "In progress." Another notification. A month later, you ship it. You publish a changelog entry, notify everyone who voted, and link back to the original feedback thread.

Those users didn't just get a feature—they got validation that their voice mattered. That's the difference between a transactional relationship and a sticky one.

The Bottom Line

Churn happens when users feel ignored. Retention happens when they feel heard.

A feedback board does three critical things:

Validates what to build so you're not guessing
Shows users you're listening through transparency and status updates
Keeps users engaged even when they're not actively using your product

You don't need a complex system. You just need a place where users can speak and where you actually respond.

If you're serious about reducing churn, start with feedback. Make it visible, make it transparent, and make it easy for users to see their impact on your product.

That's how you build a product users stick with.

Want a feedback board that actually works? UserJot handles feedback, roadmaps, and changelogs in one simple tool, designed for SaaS teams who want to reduce churn and build what users actually want.

The Solo Developer's Product Stack: 4 Things I Wish I'd Set Up From Day One

Shayan — Fri, 10 Oct 2025 18:58:22 +0000

I spent my first six months building features nobody asked for. I'd ship something—crickets. Ship something else—more crickets. I thought the problem was my code or my marketing. It wasn't.

The problem was I had no system for understanding what people actually wanted, planning what to build next, or telling anyone when I shipped something new.

Here are the four non-code things I wish I'd set up from day one.

1. Customer Feedback Tools (Stop Building on Assumptions)

The biggest mistake I made early on was building based on what I thought users wanted. I'd assume feature X was critical, spend two weeks building it, ship it, and... crickets. Meanwhile, users were asking for feature Y in scattered DMs, emails, and Twitter replies—and I had no way to see the pattern.

That's when I started using customer feedback tools to centralize everything. No more hunting through inboxes or trying to remember what someone mentioned three weeks ago. All feedback goes into one system where I can actually see what people want.

Here's what changed:

Users submit feedback directly (feature requests, bugs, improvements)
They automatically categorize their own feedback
I can see patterns instead of isolated complaints
Nothing gets lost in the noise

The key is making it easy for users to give feedback and easy for you to act on it.

Why it matters:

You can't build the right thing if you're guessing. Feedback tools give you data instead of hunches.

2. A Customer Feedback Platform (Let Users Drive the Roadmap)

Once you're collecting feedback, you need a way to manage it and show users you're actually listening. This is where a customer feedback platform becomes critical. It's not just a collection tool—it's the system that turns feedback into action and keeps users engaged in the process.

Here's how I use it:

Users vote on feature requests (so I know what's actually popular, not just loud)
Each request gets a status: Reviewing, Planned, In Progress, or Closed
The board is public, so users can see what's happening in real-time
When I update a status, users get notified automatically

The status workflow is simple:

Reviewing: I'm thinking about it, evaluating feasibility
Planned: It's on the roadmap, we're going to build it
In Progress: I'm actively working on it
Closed: Not implementing it (with a reason why)

Why it matters:

Users who feel heard stick around. Users who think you're ignoring them churn. A feedback platform turns your users into collaborators instead of complainers.

3. A Product Roadmap (Let Feedback Build Your Roadmap for You)

Here's what I love about this system: your roadmap basically builds itself. Once feedback statuses are set, your product roadmap is just a filtered view of what's Planned and In Progress. No more manual updates, no more "let me check my notes" moments. The roadmap reflects exactly what you've committed to building based on real user requests.

My roadmap structure maps directly to feedback statuses:

Now = In Progress
Next = Planned
Later = Reviewing

When a new idea pops up (and they always do), it goes into Reviewing. I evaluate it weekly, and if it's good, I move it to Planned. If not, I close it with a reason.

No more context-switching every time someone requests something shiny. The roadmap shows both in-app and on a public board, so users always know what's coming. No surprises, no broken promises.

Why it matters:

A roadmap gives you permission to say no. It also gives you a single source of truth when you inevitably forget why you decided to build X before Y.

4. A Changelog Tool (Close the Loop and Keep Users Engaged)

Here's the thing nobody tells you: if you don't tell people you shipped something, they won't notice. I used to just push updates and assume people would figure it out. They didn't. Then I started posting updates in Slack. Nobody read them. Finally, I realized I needed a proper changelog tool to close the loop.

Here's how it works:

Once I complete features (status changes to Done), I use the changelog tool to pull all completed items since the last update
It helps me quickly write a changelog entry—what changed, why it matters
The changelog automatically gets posted to the public board, emailed to users, and shown in-app
Users who requested those features get notified: "Hey, we shipped that thing you asked for"

This creates a product-led growth loop.

Users request features → you build them → you tell users → they stay engaged and tell others. Rinse and repeat.

Why it matters:

Changelogs build trust. They show you're actively working on the product, listening to feedback, and shipping consistently. They also give you an excuse to re-engage users who've gone quiet.

The Stack in Action

Here's the full workflow in practice:

User submits feedback via your feedback tools
Feedback shows up in your platform with automatic categorization
You review weekly and set status: Reviewing, Planned, In Progress, or Closed
Your roadmap automatically updates based on statuses
You build what's In Progress
When done, you use the changelog tool to pull completed items and write an update
Changelog goes out via email, in-app notification, and public board
Users who requested those features get notified
They see you're listening, and the loop continues

That's it. It's not complicated. But it took me way too long to figure out.

If I were starting over today, I'd set up these four things before I wrote a single line of product code. Not because they're sexy or because some productivity guru told me to. But because they would've saved me months of building the wrong things and wondering why nobody cared.

The One Advice I'd Give My Past Self: Build Boring Sh*t That Sells

Shayan — Mon, 15 Sep 2025 21:19:09 +0000

I've been building products full-time for several years now. If I could go back and give myself one piece of advice when I started, it would be this: stop trying to build something revolutionary and start building something people already pay for.

I know that sounds depressing. We all got into this because we wanted to change the world, not build another invoicing app. But here's the thing about building products for a living: your landlord doesn't accept GitHub stars as payment.

The Market Validation Trap

Most indie hackers start the same way. They spend months building something nobody has ever seen before. A revolutionary new approach to an old problem. A tool that's going to change how people work. Something that doesn't exist because it's so innovative.

You know what these projects usually have in common? Zero customers.

Meanwhile, you'll see other developers launch "boring" products and hit $5K MRR in three months. Another email tool. Another form builder. Another analytics dashboard. They're not changing the world, but they're changing their bank accounts.

Why Boring Works

Here's what took me too long to understand: if competitors exist, that's good news. It means people are already pulling out their credit cards for this type of solution. You don't have to convince anyone they need it. You don't have to educate the market. You don't have to wait for behavior change.

The market is already there. You just need to grab a small piece of it.

Think about it this way. There are probably 50 different project management tools. Notion, Asana, Monday, ClickUp, and dozens more. Yet Linear came along, built another project management tool, and raised millions. Why? Because the market for project management is massive. Even 0.1% of that market is enough to build a sustainable business.

Understanding Risk as an Indie Hacker

When you're building products solo or with a small team, you're not playing the same game as venture-backed startups. They can afford to take moonshots because they have 18 months of runway and investors who expect 9 out of 10 bets to fail.

You probably have 6 months of savings and a partner asking when this "building apps thing" is going to start paying bills.

Your biggest risk isn't that someone copies your idea. Your biggest risk is that nobody wants what you're building. And the best way to reduce that risk is to build something people are already buying from someone else.

The Math is Simple

Let's say you want to make $10K per month. That's a good living for most people. Here are your options:

Option A: Build something revolutionary that nobody's seen before

Market size: Unknown
Customer education needed: Massive
Willingness to pay: Unknown
Competition: None (red flag)
Time to first customer: 6-12 months maybe?

Option B: Build a simpler alternative to an existing product

Market size: Proven (just look at competitor revenues)
Customer education needed: None
Willingness to pay: Proven
Competition: Yes (validation)
Time to first customer: 1-3 months

With Option B, you need just 100 customers paying $100/month or 334 customers paying $30/month. If your competitor has 10,000 customers, you need to convince 1-3% of them to switch. That's not a moonshot. That's just execution.

How to Find These Boring Ideas

The process is embarrassingly simple:

Go to any SaaS marketplace or directory
Find products charging $50+ per month
Read their reviews and complaints
Search "[product name] alternatives" on Google
If people are searching for alternatives, you've found your opportunity

I did this with UserJot. The feedback management market was clearly proven - companies were paying hundreds per month for these tools. But when I researched deeper, I found a gap. There was room for something different in that market. The opportunity wasn't to copy what existed, but to serve the customers who weren't quite happy with their current options.

But What About Competition?

This is where most people get stuck. "But Stripe already exists!" "But there are already 100 form builders!"

Good. That means the market is validated. Your job isn't to beat all of them. Your job is to find the gap they're not filling. Every successful product leaves gaps. Maybe they've moved upmarket and abandoned small businesses. Maybe they've become too complex for simple use cases. Maybe they're missing a workflow that a specific niche needs.

Big companies can't serve everyone perfectly. They make trade-offs. Your opportunity is in those trade-offs.

The Innovation Misconception

You don't need to invent a new category. Innovation can be:

Better pricing model (no per-user pricing when everyone else has it)
Better user experience (cleaner interface when competitors are bloated)
Better support (actually answering emails when competitors use chatbots)
Different target market (freelancers when competitors target enterprise)
Regional focus (built for EU compliance when competitors are US-focused)

Stripe didn't invent payment processing. They just made it developer-friendly. Notion didn't invent docs and databases. They just put them in one place. Linear didn't invent project management. They just made it fast and keyboard-driven.

My Actual Results

When I switched from building "innovative" products to building in proven markets, everything changed. With my previous revolutionary ideas:

6 months to launch
0 paying customers after another 6 months
Constant pivoting because nobody understood the value

With UserJot (entering a proven market with clear differentiation):

6 weeks to launch
First paying customer in week 2
Clear roadmap because customers tell me exactly what they need

The difference? With UserJot, I found a proven market and identified where I could differentiate. Companies already collect feedback. They already pay for these tools. I just needed to understand what gap existed and fill it.

The Reality Check

Look, I get it. Building another email tool or form builder doesn't feel sexy. You didn't learn to code to make marginal improvements to existing products. You wanted to build the future.

But here's the reality: you can't build the future if you can't pay rent. And you can't iterate your way to product-market fit if you run out of money in month 3.

Start with boring. Make money. Then use that stability and experience to build whatever moonshot you want. But don't bet your ability to do this full-time on being the one person who successfully creates a new market from nothing.

The Checklist

Before you build your next product, ask yourself:

Are people already paying for something similar?
Can I find complaints about existing solutions?
Can I build a simpler/cheaper/better version for a specific group?
Will people understand what this is without a 10-minute explanation?
Can I point to specific companies and say "they would pay for this"?

If you answered no to any of these, you're taking on unnecessary risk.

The Practical Playbook

Here's exactly how to execute this strategy:

1. Pick Your Market
Find a category where companies spend $50-500/month. These are sweet spots, expensive enough that people pay, cheap enough that decisions happen quickly.

2. Research the Gap
Don't just copy. Find what's missing. Maybe existing tools are too complex for small teams. Maybe they're too expensive for bootstrappers. Maybe they're missing a key workflow. There's always a gap.

3. Build an MVP in 4-6 Weeks
Not 6 months. Not a year. If you can't build a sellable version in 6 weeks, the scope is too big. Cut features until you can.

4. Launch with Actual Pricing
Free trials are fine, but have real pricing from day one. You want to validate that people will pay, not just that they'll sign up.

5. Add a Feedback Board
This is crucial and most people skip it. Add a feedback board (I use UserJot for this) from day one. Let users tell you what to build next. This turns your early customers into your product roadmap.

6. Double Down on What Works
Once you get your first 10 customers, stop guessing. They'll tell you exactly what features to build, what to fix, and what to ignore.

7. Iterate Based on Feedback, Not Feelings
Your customers are already paying you. They're invested in your success. Listen to them, not your assumptions about what the market wants.

Final Thoughts

The startup media loves stories about revolutionary products that created new categories. Those stories are exciting. They're also survivorship bias in action. For every Uber, there are 10,000 "Uber for X" companies that died because the market didn't exist.

You don't need to be revolutionary to build a sustainable business. You just need to be useful to enough people who are already paying for something similar.

Find a proven market. Build something a little better, cheaper, or simpler. Get to $10K MRR. Then worry about changing the world.

Your past self will thank you when you're actually doing this full-time instead of going back to a day job after your savings run out.

Why Good Products Fail: A Reality Check on Marketing

Shayan — Fri, 12 Sep 2025 18:34:58 +0000

A lot of products fail, not because they're bad, but because no effort went into marketing them. This isn't a hot take or some profound wisdom. It's just reality that many of us struggle to accept.

Build it and they will come doesn't work

This might be the most persistent myth in tech. The idea that if you just build something good enough, users will magically find it.

It only works for maybe the top 1% of products. The ones that hit some perfect combination of timing, luck, and virality. Most of us aren't in that category, and that's completely fine. Even the products that seem to grow effortlessly are usually backed by serious marketing efforts you don't see.

You've probably seen it yourself. Someone's first app somehow gets into that lucky 1%. Their second app? Not so much. That's the reality for most of us.

Why marketing feels so hard for developers

There's an uncomfortable truth here: many developers think marketing is a little beneath them. A little embarrassing even.

We have no real concept of the scale required to actually try at marketing. We'll spend weeks perfecting a feature but give up on marketing after a few tweets don't land.

The success rate of marketing hurts too. You might try ten different things before something works. For people used to deterministic outcomes in code, this feels broken. You can do everything right, make some sales, keep pushing, and still hit a roadblock. Progress isn't linear.

What actually works

Here's what developers who've had success are doing:

Programmatic SEO: Building pages at scale to capture search traffic. It's technical enough that developers don't hate it.

Paid ads: Google Ads can be a way to speedrun things if you take time to learn it. The learning curve is steep but the results can be immediate.

Content marketing: Writing blog posts, tutorials, documentation. This feels more natural for developers since it's educational.

ProductHunt launches: Can give you that initial boost and community support. Not a long-term strategy but good for validation.

Community building: Engaging on Twitter, Discord, Reddit. Being helpful without being pushy.

Nobody knows which channel will work for their specific product. You have to try multiple approaches and see what sticks.

The feedback loop problem

Here's something most developers miss: marketing isn't just about shouting into the void. It's about understanding what resonates with your audience. You need a way to track what's working and what isn't.

This is where having a proper feedback system helps. When users do find your product, you need to understand why they stayed or why they left. What features do they actually want? What problems are they really trying to solve?

We built UserJot partly because we saw teams struggling with this. They'd launch features nobody asked for while ignoring the feedback sitting in their email. A simple feedback board can tell you more about your market than any amount of guessing. Plus, when potential users see an active feedback board with real responses, it builds trust. They know you're actually listening.

The uncomfortable truth about effort

Half of marketing is just being louder and more persistent than the competition. It's not elegant. It's not clever. It's just persistent effort.

Marketing is a hustle. You have to keep trying different things until something clicks. There's no magic formula or secret hack. Just consistent experimentation and learning from what doesn't work.

The amount of effort you put into marketing is inversely proportional to how much ego you have as a founder. The more precious you are about "just focusing on the product," the less likely you are to do the unglamorous work of getting people to actually use it.

Moving forward

If your product has three users and you're still tweaking features, stop. Go talk to people. Write about what you're building. Share your progress. Try paid ads. Build in public. Answer questions in communities where your users hang out.

Yes, it feels uncomfortable. Yes, the success rate is low at first. Yes, you'll feel like you're bothering people.

But the alternative is a great product that nobody knows exists.

Even the best product in the world can't sell itself. Neither can you. Marketing isn't optional anymore. It's just part of building something people will actually use.

The good news? You don't have to be perfect at it. You just have to start. Pick one channel, give it an honest try for a few weeks, measure the results, and adjust. That's it. No revolutionary strategies required.

Your code might be flawless, but if nobody knows about it, what's the point?

The Backwards Way to $10K MRR: Build SEO First, Product Second

Shayan — Wed, 10 Sep 2025 18:56:38 +0000

Most developers build products first and worry about customers later. It makes sense on the surface. You have an idea, you're excited about it, so you start coding. But this approach is incredibly risky. You might spend months building something nobody searches for, solving a problem nobody has, or creating a solution people won't pay for.

The problem is that 90% of startups fail, and the number one reason is no market need. That's thousands of hours and dollars wasted on products that never had a chance.

But what if there was a different way? A way to validate demand before writing a single line of product code? A method that's more predictable, less risky, and actually tells you what to build?

This post is about finding keywords with massive search volume, building SEO content to rank for them, and only building products after you've validated demand with actual traffic.

The Traditional Approach vs. The Backwards Way

Traditional: Idea → Build Product → Launch → Marketing → Hope for Users

Backwards: Keyword Research → SEO Content → Traffic → Validation → Build Product

The backwards way ensures you're building something people are already searching for. No guessing, no hoping. Just data-driven product development.

How the SEO-First Strategy Works

Step 1: The Keyword Hunt

Find 10 keywords across different niches with these criteria:

Search volume: 10,000-100,000/month
Keyword difficulty: Under 30
Commercial intent: People willing to pay for solutions

Examples:

"invoice generator free" (50K searches/mo)
"pdf to excel converter" (75K searches/mo)
"qr code api pricing" (25K searches/mo)
"color palette generator" (90K searches/mo)

Step 2: The Shotgun Approach

Instead of betting everything on one idea, spread your bets:

Register keyword-rich domains ($10-15 each)
- invoicegeneratorfree.com
- pdftoexcelconverter.io
- qrcodeapi.dev
Build simple landing pages (same template for all)
- Hero section explaining the tool
- Feature list
- Pricing (even though product doesn't exist yet)
- Email capture or UserJot widget for feedback
Create SEO content (3-5 posts per site)
- "How to create invoices for free"
- "PDF to Excel conversion guide"
- "Best practices for QR code generation"
Basic link building
- Submit to directories
- HARO responses
- Guest posts in relevant niches

Total time investment: 2-3 hours per site
Total cost: ~$200 for all 10 sites

Step 3: Wait and Watch

After 2-3 months, you'll see patterns:

2-3 sites start ranking (page 1-2)
3-4 sites show promise (page 3-5)
3-4 sites go nowhere

Double down on the winners with more content. Abandon the losers.

Step 4: Build Only What Ranks

Once a site hits page 1 and gets 1000+ visitors/month, build the simplest possible version:

Invoice Generator Example:

Ranked #6 for main keyword
3,000 visitors/month
Built basic invoice generator in a weekend
Added Stripe, charged $9 one-time
Now generates $2-3K MRR

Your MVP only needs the one core feature people searched for. Nothing more.

Step 5: Let Users Drive the Roadmap

This is where tools like UserJot become crucial. Once you have paying customers:

Add feedback widget to your site
Let users tell you what features they need
Build based on actual demand, not assumptions

Your initial SEO traffic becomes your research panel. They're already interested in your solution. Now they'll tell you exactly how to make it better.

Why This Works

1. Validated Demand
If 50,000 people search for something monthly, the demand is proven. You're not guessing.

2. Low Risk
Failed experiments only cost $20-30. One success pays for 100 failures.

3. Fast Feedback
Within 2-3 months, Google tells you which ideas have potential. No need to build anything that won't work.

4. Built-in Distribution
SEO traffic is free and compounds over time. While others pay for ads, your customers find you naturally.

5. Clear Monetization Path
People searching for tools have intent to use (and pay for) solutions.

Real-World Results

Here's what's possible with this approach:

Simple PDF tools: $5-15K MRR (one-time payments)
API services: $10-30K MRR (subscriptions)
Developer tools: $8-25K MRR (tiered pricing)
Business tools: $10-50K MRR (B2B pricing)

The best part? Many of these can run mostly on autopilot once built.

Common Objections

"But I want to build something I'm passionate about"

Build passion projects on the side. Use profitable micro-SaaS to fund them.

"This creates low-quality products"

Not if you listen to users. Start simple, then improve based on feedback. Many successful SaaS started as simple tools.

"SEO takes too long"

3 months to validate is faster than 6 months building the wrong thing.

The Implementation Playbook

Month 1:

Research 10 keywords
Buy domains
Build landing pages
Start content creation

Month 2:

Finish initial content
Basic link building
Set up analytics

Month 3-4:

Monitor rankings
Double down on winners
Start building products for top performers

Month 5-6:

Launch products
Add payment processing
Implement user feedback tools
Scale winners

Don't Let That Traffic Go to Waste

Once you have traffic and start building your product, you need to understand what features to build next. Your SEO traffic is gold. These are people actively searching for solutions. You need to capture their feedback before they leave.

For this, I use UserJot. It's a feedback, roadmap, and changelog tool that works perfectly with this strategy:

Instant Feedback Collection: Add a simple widget to your landing page (takes 30 seconds). Now every visitor who found you through SEO can tell you exactly what they need.

Validate Feature Ideas: Your SEO traffic is pre-qualified. They searched for your solution. When they request features, you know there's real demand.

Public Roadmap: Show visitors what you're building next. This converts more trial users because they see you're actively developing the product.

Keep Users Engaged: Automatic changelog notifications keep your early users coming back as you add features they requested.

The best part? UserJot has a generous free plan that's perfect for micro-SaaS products just starting out. You can collect unlimited feedback from unlimited users without paying anything until you need advanced features like SSO or integrations.

Think of it this way: your SEO brings them in, your simple tool converts them, and a good feedback system tells you how to keep them. That's the complete backwards building approach.

The Bottom Line

Building products backwards (SEO first, product second) flips the risk equation. Instead of building and hoping, you validate with traffic first. It's not glamorous, but it works.

Start with 10 keywords this weekend. In 6 months, you could have 1-2 profitable micro-SaaS products generating steady MRR.

My SaaS Infrastructure as a Solo Founder

Shayan — Mon, 08 Sep 2025 16:52:49 +0000

I built and run UserJot completely solo. No team, no contractors, just me.

UserJot is a feedback, roadmap, and changelog tool for SaaS companies. It helps product teams collect user feedback, build public roadmaps, and keep users updated on what's shipping. The infrastructure needs to handle significant traffic. In August alone we had 52,000 users hitting the platform, feedback widgets loading on customer sites, and thousands of background jobs processing.

Here's the setup I've landed on after months of iteration.

The Setup

I have three frontends, all deployed on Cloudflare Workers:

Astro for marketing pages, blog, and docs (mostly static with minimal JavaScript)
TanStack Start for the dashboard (server-rendered, then becomes a SPA)
TanStack Start for public feedback boards (same approach)

Why TanStack Start? It takes the good ideas from Remix and pushes them further. Next.js has gotten bloated with too many features and abstractions. TanStack Start is simpler and more predictable.

One backend cluster:

Docker Swarm on Hetzner (US East)
Node.js with TypeScript
PostgreSQL
Caddy for reverse proxy

That's the entire infrastructure. Deployment happens through GitHub Actions that runs CI/CD and deploys to Docker Swarm. Simple, boring, works.

Why No Redis

PostgreSQL handles everything:

Job queues using pg-boss
Key-value storage in a JSONB table
Pub/sub with LISTEN/NOTIFY
Vector search with pg-vector for finding duplicate feedback
Session storage
Rate limiting

pg-boss has been rock solid for job queues. It's processing thousands of jobs daily: email drip campaigns, notification triggers, data syncing. It has some limitations compared to dedicated queue systems since it's built on PostgreSQL, but nothing that's actually mattered in practice.

Could Redis do some of this better? Probably. But managing one database is simpler than managing two. When you're solo, every additional service is something else that can break.

More importantly, every dependency directly affects your uptime. Two services means twice the things that can fail. Twice the things to monitor. Twice the things to back up. Twice the things to upgrade. Your availability is only as good as your weakest service. Every new service is another thing that can break at 2am.

Sure, at some point I might need Redis for caching. Or RabbitMQ for complex queue patterns. Or Kafka for event streaming. But that's a very, very long way off. And honestly? I'm not looking forward to adding those dependencies.

Single Region, Global Users

The backend runs in one location: US East.

Three things make this work globally:

Cloudflare Argo reduces latency by routing traffic through their network
Optimistic updates in the UI make actions feel instant
Prefetching loads data before users click

The frontends render on Cloudflare's edge, so users get HTML from a nearby location while the data loads from the backend.

Serverless Where It Makes Sense

I use serverless for the frontends because they're stateless. They just render HTML and proxy API calls. No persistent connections, no background jobs, no state to manage.

But the backend is a traditional server. You need connection pools for PostgreSQL. You need long-running processes for job queues. You need WebSocket connections for real-time features. Serverless isn't great at these things.

This split works well:

Frontends scale automatically on the edge
Backend runs predictably on dedicated servers

The Trade-offs of Self-Hosting

I self-host PostgreSQL and the backend cluster. This takes more work than using managed services, but I get:

Full control over PostgreSQL extensions and configuration
Ability to run pg-boss, pg-vector, and other tools
Predictable costs that don't scale with usage
No vendor lock-in

The downside: I handle backups, updates, and monitoring myself. If you value your time more than control, managed services might be better.

When This Makes Sense

This architecture works well when:

You're one person or a small team
You want to own your infrastructure
You're comfortable with PostgreSQL and Docker
You don't need multi-region data replication
Your features don't require complex real-time sync

It probably doesn't make sense if:

You have a large team that needs managed services
You need true multi-region presence
You're not comfortable managing servers
You need specialized databases for specific features

What I've Learned

PostgreSQL can do more than you think. Job queues, caching, pub/sub. It handles all of these reasonably well. You might not need that Redis instance yet.

Stateless frontends simplify everything. When your edge workers just render and proxy, there's no distributed state to worry about.

Single region is fine for most SaaS apps. With good caching and optimistic UI updates, users won't notice if your server is far away.

Boring technology works. Docker Swarm isn't as fancy as Kubernetes, but it's simpler and does the job.

Over-provision your servers. VMs are cheap. Having 4x the capacity you need means you never have to think about scaling during a traffic spike. Peace of mind is worth the extra $50/month.

The Reality of Maintenance

The hardest part was the initial setup. Understanding how all the pieces fit together takes time and experience. But once it's running? I spend maybe 2-3 hours per month on infrastructure.

Everything else is building features and talking to users.

Moving Forward

Will this scale forever? No, but it'll scale way further than most people think.

People seriously underestimate how much a single PostgreSQL instance can handle. Modern hardware is insanely powerful. You can scale vertically to machines with hundreds of cores and terabytes of RAM. PostgreSQL can handle millions of queries per second on the right hardware.

This setup could easily handle hundreds of thousands of active users, maybe millions, depending on your usage patterns. It might be all I ever need.

For now, and probably for years to come, PostgreSQL and a simple architecture is enough. I'm shipping features, talking to users, and growing the business. The infrastructure just works.

If you're curious about UserJot, check it out at UserJot. Always happy to chat about infrastructure decisions. Find me on Twitter/X.

How to Actually Hit $10K MRR in 2026 (No BS, Just What Works)

Shayan — Sat, 06 Sep 2025 19:03:50 +0000

I've grown two SaaS products to decent MRR. But I've had many that failed, and it took a long time to get to the ones that actually worked.

If I were starting over in 2026, clean slate, zero dollars in the bank, no existing audience, this is exactly how I'd push to $10K MRR.

Just the practical steps I wish I'd followed earlier, based on what actually works for bootstrapped founders.

Nail your ICP before you build anything

Your ideal customer profile (ICP) isn't some vague "small businesses." Get specific: Who are they? What's their daily grind? What problem keeps them up at night that they're already paying to solve?

I'd spend the first 1-2 weeks interviewing 20-30 people in a niche I know, like indie devs or small agency owners. Use free tools: LinkedIn searches, Reddit threads, or even cold DMs. Ask: "What's the one tool you hate but can't live without? Why?"

Look for patterns in their frustrations. If multiple people complain about inefficient email marketing or fragmented analytics dashboards, that's your entry point. Don't chase shiny trends like AI wrappers unless they fix a real, boring pain.

This step saves months of building the wrong thing. Without it, you're just guessing, and guesses rarely hit $10K.

Build a minimum lovable product, not just viable

Forget the bare-bones MVP that barely works. Aim for something simple but delightful, enough to get early users hooked and paying.

Since AI has made it easy for a lot of folks to build code apps quickly, it's important that you spend more time on the MVP and build the minimum lovable product instead of just viable, because everyone can do that right now.

Pick a tech stack you can ship fast with: TanStack Start or Remix for the frontend, Postgres for the backend, maybe Stripe for payments. No overkill like Kubernetes. Focus on core functionality: Solve that one pain point exceptionally well.

Test it on those interview folks. If they don't say "This is better than what I have," iterate until they do.

Your goal: Launch with 3-5 features that make users think, "Finally, someone gets it."

Charge early and price for value

"Free beta" sounds safe, but it attracts tire-kickers who vanish when you ask for money. Start charging from day one, even $29/month, to filter for serious users.

Price based on the value you deliver, not your costs. If your tool saves a small team 10 hours a month at $50/hour, $99/month is a steal. Test tiers: Basic for solos, pro for teams.

Use free calculators like the Pricing Sensitivity Simulator to model this. I'd aim for an average revenue per user (ARPU) around $50-100 to hit $10K with 100-200 customers. Track payback period: recover CAC in under 6 months, or tweak.

Charging weeds out the noise and validates you're building something worth paying for.

Talk to users constantly, make it a habit

Users aren't just revenue; they're your roadmap. Set up a feedback loop from launch: Embed a simple widget in your app for quick submissions.

I'd use something like UserJot (the tool I built) for a public board where users post ideas, upvote, and see what's coming. It turns passive users into engaged ones; they feel ownership. The key is to make it dead simple for users to share thoughts: public boards encourage more input because people see others contributing and feel part of a community. This way, you're not guessing what to build next; your users tell you directly and help prioritize what matters most.

Schedule weekly calls with 5-10 users. Ask: "What's working? What's frustrating? What one change would make you stay forever?" Don't ignore the complaints; they're your growth fuel.

This keeps churn low (aim for under 5% monthly) and retention high, which compounds to $10K faster than constant acquisition.

Market relentlessly, but smart, not scattershot

Marketing isn't a side gig; it's 60% of your time. But don't spray and pray.

Build in public: Share your journey on X, Indie Hackers, and Reddit's r/SaaS. Post threads like "Week 1: Interviewed 20 users, here's what I learned." It builds trust and attracts early adopters.

Focus on 2-3 channels: SEO for long-tail keywords (e.g., "best feedback tool for indie devs"), cold outreach to your ICP via LinkedIn, and content like blog posts on pains you solve.

No paid ads yet, too expensive for bootstrappers. Instead, leverage communities: Offer beta access for honest reviews. Track what brings signups (use your Revenue Run Rate Calculator) and double down.

Consistency here turns $0 into your first $1K MRR.

Do the unscalable stuff yourself

At this stage, you're the sales team, support, and marketer. Hand-hold every user: Personally onboard them, fix bugs overnight, send thank-you notes.

Cold email 50 prospects a week: "Saw your post about [pain point]. Built something that might help, want a quick demo?" Keep it personal, not spammy.

Partner with complementary tools: If you're in feedback, collab with CRM folks for cross-promos. This gets you users without ad spend.

It's grunt work, but founders who do it hit $10K faster. Outsource only when you're at $5K and drowning.

Track key metrics, no vanity BS

Don't obsess over page views. Focus on what moves the needle: MRR growth, churn, CAC, LTV, and quick ratio (new revenue vs. lost).

Use free tools like your CLTV Calculator or Quick Ratio Calculator to monitor. Aim for: 20-30% monthly growth early on, CAC under $200, LTV 3x CAC.

Review weekly: If churn spikes, dig into feedback. If growth stalls, tweak pricing or marketing. Data keeps you honest; without it, you're flying blind.

Iterate fast and say no to distractions

You'll get feature requests galore. Prioritize ruthlessly: Use upvotes from your feedback board to decide what's next.

Ship small updates weekly, post about them to keep momentum. If something doesn't boost retention or acquisition, cut it.

Avoid shiny objects: No pivots unless data screams for it. Stay focused on your ICP's core pain.

This compounding, better product + happier users, gets you to $10K sustainably.

Build retention into everything

$10K isn't about 10,000 signups; it's 100 loyal customers paying $100/month.

Delight them: Send drip emails on wins (e.g., "Your feedback just shipped!"), share roadmaps publicly, and fix issues before they complain.

Track stickiness (DAU/MAU) and net promoter score. High retention means less acquisition grind; your users become advocates.

Final thought: It's about persistence, not perfection

Hitting $10K MRR in 2026 won't be easy. You'll face crickets, churn, and self-doubt. But focus on solving real problems, listening to users, and showing up daily; it compounds.

This is the playbook I'm using to grow UserJot right now. If it helps, steal it. :)