The Indie Hacker's Guide to Validating a Product Before You Build It

Product validation is the process of confirming that real people want your solution badly enough to use it, and ideally pay for it, before you invest weeks of engineering into building it. For indie hackers, the goal is simple: spend a few days getting signal instead of a few months getting silence.

Most failed indie apps don't fail because the code was bad. They fail because the maker built in a vacuum, launched to crickets, and only then discovered nobody had the problem they were solving. Validation flips that order.

What does validation actually mean?

Validation is not asking your friends if your idea is cool. Friends are supportive and useless as a signal. Real validation means watching a stranger take an action that costs them something: time, attention, an email address, or money.

There are three levels of signal, from weakest to strongest:

• Stated interest — someone says "I'd use that." Cheap to give, means little.
• Demonstrated interest — someone joins a waitlist, books a call, or replies to a recruitment post. Costs them effort.
• Committed interest — someone pre-pays or shows up to test on day one. This is the only signal that reliably predicts a real launch.

Aim for demonstrated interest before you build, and committed interest as soon as a prototype exists.

A four-step validation sequence that works

1. Write the problem before the solution. In one sentence, describe the painful situation your user is in today, without mentioning your app. If you can't write that sentence, you don't have a product — you have a feature looking for a problem.

2. Find ten people living that problem. Go where they already complain: Reddit threads, Discord servers, X replies, niche forums. Their language becomes your landing page copy.

3. Put up a lightweight offer. A single landing page with a clear headline, the problem, your promised outcome, and one call to action. Drive a couple hundred targeted visitors to it. A flat zero is information too.

4. Recruit your first testers before the product is finished. If you can get even ten people to agree to test an unfinished thing, you've validated demand and lined up your first feedback loop. If nobody will agree to test it for free, that is the validation result, and it just saved you three months.

The mistake that kills momentum

The most expensive validation mistake is treating "build it" and "find users" as sequential phases. Makers build for two months in isolation, then go looking for testers, then discover the core assumption was wrong. Run them in parallel. The day you start building, start recruiting. A platform like IndieCrush exists for exactly this, but the principle holds regardless of the tool: never build longer than you can stand to throw away.

Frequently asked questions

How long should validation take?

For a single feature or small app, a few days to two weeks. If you've spent a month "validating" without building anything testable, you're procrastinating, not validating.

Can I validate without a landing page?

Yes. Direct conversations and recruitment posts in communities where your users already gather are often faster and richer than a landing page for very early ideas.

What if people say they'd use it but then don't?

That's normal, and exactly why stated interest is the weakest signal. Always push for a costly action: a signup, a booking, or a commitment to test.

Want feedback from real testers within 24 hours of shipping your prototype? That's what we built IndieCrush for.