If you have already shipped something that nobody bought, you know the feeling. Months of nights and weekends, a launch day with a handful of visits, and a quiet inbox afterward.
The usual advice is "validate first." That is true, but it is vague. What does validation actually look like? This article gives you a short checklist of the evidence to collect before you write code, plus a simple way to decide whether to build, test smaller, or walk away.
Why good builders still ship things nobody wants
Failed launches rarely come from bad engineering. They come from skipping the question of whether anyone is already trying to solve this problem.
A few patterns show up again and again:
- You validated with people who like you. Friends, followers and family say "cool idea." That is politeness, not demand.
- You started from a solution. You found a clever approach and went looking for a problem that fits it.
- You mistook interest for need. Someone saying "I'd probably use that" costs them nothing. Someone already paying, or already hacking together a workaround, has shown you something real.
- You treated research as a phase to finish. You ran a survey, got mild positive answers, and moved on to building.
The fix is not more research for its own sake. It is collecting a specific set of evidence, and being willing to stop if you can't find it.
The pre-build checklist
Work through these in order. If you can't tick an item, that is useful information, not a failure.
1. A specific person with a specific problem
Write one sentence: "[Type of person] struggles with [specific task] when [situation]."
"Small businesses need better marketing" fails this test. "Freelance consultants lose hours every time they onboard a client because they redo the same manual analysis" passes it.
If you can't name the person and the moment the problem happens, you are not ready to build. You are still picking a topic.
2. The problem described in their words, not yours
Find at least a few places where real people describe the problem unprompted. Copy the exact wording. Don't paraphrase it into marketing language.
Here is an example of what usable evidence looks like. A poster in r/entrepreneur wrote:
"Every time i took on a new client i was doing the same manual analysis over and over. Go through their website, check the SEO, read the copy, look at competitors, figure out where they're leaking money."
Notice what is in there: a repeated task, a clear trigger (a new client), and a cost (time, plus money leaking). You can build a product hypothesis from that. You can't build one from "people want better SEO tools."
Another, from r/sysadmin:
"8 months post-acquisition and we still have 200 people with active accounts in both tenants. Some line-of-business apps were never migrated."
This one has a timeline, a number, and a consequence. It also shows the problem has lasted months, which suggests nobody has solved it cleanly.
One caution: a single post is a lead, not proof. It tells you where to look. The next items tell you whether it matters.
3. Proof it comes up repeatedly
One person complaining is an anecdote. Ten people in different threads, months apart, describing the same problem is a pattern.
Look for:
- The same complaint across several communities or job titles
- Threads where the replies say "same here" or "I have this problem too"
- Questions asked again and again with no satisfying answer
A useful habit is keeping a tally. Every time you find a new mention, log the link and the quote. If you can't get past two or three after a serious search, treat that as a warning.
4. Signs the pain is intense
Frequency tells you how many people. Intensity tells you how much they care.
Strong signals include:
- Specific costs: hours lost, clients lost, money wasted
- Emotional language: frustration, dread, "I hate doing this"
- A problem that blocks other work, rather than a minor annoyance
- People describing how long they've lived with it
Weak signals include polite wishes ("it would be nice if...") and feature requests for a tool the person already uses and is mostly happy with.
5. Evidence that people already spend to solve it
This is the item most failed launches skip. Willingness to pay doesn't show up in a poll. It shows up in behavior.
Check whether people currently:
- Pay for an existing tool, even a flawed one
- Hire freelancers or agencies to handle it
- Spend hours on a manual workaround (time is a cost too)
- Complain about the price of current options, which means they are buying them
If a problem is painful but nobody has ever paid to fix it, be careful. Some problems are real and still unmonetizable.
Existing competitors are not automatically bad news. Paid competitors are often the clearest proof that demand exists. Your job is to find what they leave unsolved.
6. Five to ten real conversations
Reading about a problem is not the same as hearing someone describe it live. Aim for a handful of short conversations with people who have the problem.
Keep them short and focused on the past, not the future:
- "Tell me about the last time this happened."
- "What did you do about it?"
- "What did that cost you?"
- "Have you tried to fix it with a tool or by paying someone?"
Avoid pitching your idea. Ask about what already happened, because people are bad at predicting what they'd do and good at reporting what they did.
If you found the person through a public post, a polite, no-pitch message asking for ten minutes is a reasonable start. Say plainly that you're trying to understand the problem before building anything. Many people ignore these messages, so contact more people than you think you need.
7. A way to reach these people again
A real problem is not enough. You need to be able to find the people who have it, cheaply.
Ask yourself:
- Where do these people already gather, online or offline?
- Can I reach them without a big ad budget?
- Is there a community, newsletter, or search term I can show up in?
If you can't answer this, you may build something useful and still have no one to sell it to.
8. A smaller test you can run in days, not months
Before building the full product, find the cheapest test that would show real commitment. Options include:
- Doing the job manually for a few people, as a service
- A simple landing page that describes the outcome, with a way to join a waitlist or pay
- A pre-sale or deposit from a small number of buyers
- A spreadsheet, script or template you deliver by hand
The goal is a behavior that costs the other person something: their email, their time, or their money. Compliments don't count.
9. Your kill criteria, written down in advance
This one protects you from yourself. Before running the test, write: "If I don't see X by [date], I will stop or change direction."
X should be concrete, for example a number of conversations where the person describes spending money or time on the problem, or a number of people who commit to a pre-order. Without a written threshold, it is easy to explain away weak results and keep building.
A quick scorecard
Give each item a simple rating: strong, mixed, or missing.
- Mostly strong, with spending evidence: go build the smallest version.
- Strong on pain but weak on spending or reach: run a manual service or pre-sale test first.
- Mixed across the board: narrow the audience and repeat the research.
- Mostly missing: drop the idea. This is the checklist doing its job.
The point is not to pick winners with certainty. It is to catch weak ideas early, before you invest months of work.
Where to find evidence faster
People tend to be blunt when they're venting in public communities, which is why Reddit is a common place to look for problems. You can search it by hand, and many founders do. It works, but it is slow and easy to get wrong. You tend to remember the dramatic posts and lose track of the quieter, repeated ones.
The main trap is confusing venting with willingness to pay. A post with a hundred upvotes tells you people sympathize. It doesn't tell you anyone would pay. Always go back to items 4 and 5.
If you'd rather not do the scanning by hand, SaasNiche scans Reddit communities and surfaces pain points scored 0–100 for intensity, frequency and willingness to pay, backed by verbatim user quotes. Treat those scores as a starting shortlist. You still need the conversations and the small test.
A one-week plan
If you want a simple structure, try this:
- Day 1: Write your one-sentence problem statement for a specific person.
- Days 2–3: Collect quotes and links. Log every repeat mention. Note existing tools and what people say about them.
- Days 3–5: Reach out and hold as many short conversations as you can.
- Day 6: Set up your smallest test and your kill criteria.
- Day 7: Launch the test to the people you've been talking to.
Before you write the next line of code
You don't need certainty, but you do need evidence: a specific person, their own words, repeated mentions, real cost, existing spending, a few conversations, and a small test with a clear stop rule.
If you want a head start on the first few steps, you can try SaasNiche through its Starter plan, which includes a 7-day trial (a card is required to start).
FAQ
How do I know if people will actually pay for my product before I build it?
Look for behavior, not opinions. People who already pay for a tool, hire someone, or spend significant time on a workaround have shown they value a fix. The strongest test is a pre-sale or deposit. A waitlist signup is weaker, and a compliment is weaker still.
How many customer interviews are enough?
There is no universal number. Many founders start with five to ten and keep going until new conversations stop surprising them. If the first several people describe the problem differently or don't care much, that is a result in itself.
Is Reddit a reliable place to validate a business idea?
It is a good place to find problems, because people describe them in their own words. It is not proof of demand on its own. Posts can reflect venting, a small group, or a one-off situation. Use Reddit to generate leads, then confirm with conversations and a small paid or commitment-based test.
What if a competitor already exists?
It is not automatically a reason to stop. Competitors often show that people pay for a solution. Read their reviews and complaints to find gaps, such as a narrower audience, a missing workflow, or a different price model. If you can't find a gap, that is a reason to rethink.
When should I give up on an idea?
When you miss the kill criteria you set before the test. Decide the threshold in advance, such as a minimum number of people who commit time or money. If you fall short, narrow the audience once and test again. If you fall short a second time, move on.