How to Validate a Startup Idea Before You Build It

Most ideas die in a specific way. You get excited, you spend three months building, you launch, and nothing happens. The idea was never checked against anything except how it sounded at 2 a.m.

Validation is not a survey, and it is not a landing page you paid to advertise. It is the work of finding out whether the problem exists in other people’s lives, in their words, before you start writing code.

Validation Starts With Evidence

Opinions are cheap and polite. Evidence is specific and inconvenient.

Weak validation:

• Asking friends whether they would use it.
• Reading your own idea back to yourself.
• Counting upvotes on a joke about your category.

Strong validation:

• Finding the same problem described by strangers in different places.
• Seeing that people already pay, in time or money, to work around it.
• Reading what they tried and why it failed.

None of that requires a product to exist. You are testing the problem, not the solution, and that is the step most people skip.

The second list takes longer and saves months. The point is not to prove yourself wrong. It is to find out what is true while it is still cheap to change your mind.

What Counts as Evidence

Not everything you read is equal. Rank what you find:

1. A description of a workaround. “I do this in a spreadsheet every week” beats “someone should build this.”
2. A cost. Hours, subscription fees, refunds, hired help, or a missed client.
3. Repetition across time. The same problem in threads posted a year apart.
4. A frustrated purchase. “I pay for this and it still does not do X.”

One of these is a signal. Two is a pattern. Three is a product question worth asking.

Building an Evidence File

The file is boring, and that is the point. For each item, record:

• The problem in one sentence.
• The exact quote, copied rather than paraphrased.
• The source and the date.
• What the person does today to cope.
• What would have to be true for a tool to remove it.

Paraphrasing is where your bias gets in. If you keep only your summary of a quote, you remember the version that supports your idea. Keep the file in plain text. Tools change and exports break, and a file you can open in five years is worth more than a neat dashboard you will abandon.

A Concrete Search Pass

Pick one community and one related community. Run these searches in each:

• “is there a tool that”
• “how do you all handle”
• “I still do this manually”
• “takes forever”
• “I hate that I have to”
• “what do you use for”

Then search the same communities for complaints about the tools people already pay for: “switched from”, “canceled”, “too expensive”, “too complicated”. Copy everything that describes a repeated task into your evidence file.

Spend an hour on this. If the file has five solid quotes from five different people, the problem is real enough to keep exploring. If it has one quote and a lot of your own reasoning, it is not.

Repeat the pass a week later. Problems that survive a second reading deserve the next step, and the rest were only interesting on the first day.

What Validation Cannot Tell You

• Whether people will pay your price. Evidence shows pain, not willingness to pay.
• Whether you can build it profitably. That is an engineering question, not a research one.
• Whether you will enjoy the work. Reading cannot answer that.
• Whether the market will still care in two years.
• Whether the person describing the problem is the person who holds the budget.

Validation is a filter for bad ideas, not a guarantee for good ones. It tells you which ideas deserve the next hour of your attention.

FAQ

How long should validation take?

Long enough to collect quotes from people you have never met, short enough that research does not become a full-time job. A focused week of reading beats three months of thinking. If you cannot find a single quote from a stranger, that is a result as well.

Do I need to talk to customers before building?

It helps, but do the reading first so your questions are specific. Asking “would you use this?” gives you nothing. Asking “how do you handle this today?” gives you the actual workflow.

What if I already started building?

Stop and read. It is much cheaper to change direction while the product is small. Find out which part of the problem people describe most often, and keep that part.

What if I find evidence that the idea is weak?

That is the best outcome of the week. You spent an hour instead of three months, and you still have the quotes, which often point at a nearby problem that is stronger.

You do not need permission to build. You need evidence that someone else already cares. Gather the quotes, count the repetitions, and only then decide. If you want the reading done for you, a report takes two to four minutes and costs 2.99 EUR and every quote in it is checked against the original text. If you prefer to do it by hand, start with how to find SaaS ideas on Reddit, then read how to do pain point research.