Guide
March 24, 20268 min read

How to Validate a Startup Idea Before Building Anything

By Dean O'Meara · Founder, Wrapt

The graveyard of failed startups is full of products that worked perfectly but solved problems nobody cared about. Validation is not about proving your idea is good. It is about finding out whether it is bad before you waste months building it. Here is a framework that takes days, not months.

Start with the problem, not the solution

Write down the problem you think you are solving in one sentence. Then ask yourself: who has this problem? How often do they have it? How do they solve it today? If the answer to any of those is vague, you are starting from assumptions, not evidence. The best startup ideas come from problems the founder has experienced personally. But personal experience is not the same as market demand. You might have a problem that only affects fifty people worldwide. That is not a business. Before you sketch a single wireframe, you need to know that enough people have this problem, that they care enough to pay for a solution, and that existing solutions leave them frustrated.

Talk to twenty strangers

Not friends. Not family. Not people who will tell you what you want to hear. Find twenty people in your target market and ask them about the problem. Not your solution. The problem. The Mom Test by Rob Fitzpatrick is the best guide on how to do this without biasing the conversation. The key rules: never tell them your idea during the interview. Ask about their life and behaviour, not their opinions. Ask about the past, not hypothetical futures. "Would you use a tool that does X?" is a useless question because everyone says yes to hypotheticals. "How did you handle X last time it happened?" is gold. If twenty people describe the same frustration in their own words, you have a signal.

Test demand before building

A landing page with an email signup is the minimum viable test. Describe the problem and the solution in plain language. Add a single call to action: "Join the waitlist" or "Get early access." Drive traffic to it using the communities where your target customers hang out. Reddit, LinkedIn, Twitter, Indie Hackers, Hacker News, or niche forums. If you cannot get fifty signups in two weeks, your positioning is wrong, your audience is wrong, or the problem is not painful enough. This test costs nothing except a few hours of your time and tells you more than months of building ever could.

Get someone to pay before you build

The strongest validation signal is money. Not a promise to pay. Actual money exchanged. This sounds extreme for a product that does not exist yet, but it works. Offer a pre-sale at a discount. Offer to solve the problem manually for your first five customers while you build the automated version. A consulting engagement where you do the work by hand proves that people will pay for the outcome. If they will pay you to do it manually, they will pay software to do it faster. If nobody will pay even at a discount for early access, you do not have a pricing problem. You have a value problem.

Study the competition properly

No competitors is not a good sign. It usually means there is no market. Lots of competitors is not a bad sign. It means the market is proven and you need a clear angle. Look at what existing solutions do well and where their users complain. App store reviews, G2 reviews, Reddit threads, and Twitter complaints are free market research. Your job is to find the gap that existing products leave open and decide whether that gap is big enough to build a business in. If your only differentiator is "we will do the same thing but better," you do not have enough of an edge. Better is subjective. Different is measurable.

Set a kill criteria

Before you start validating, decide what failure looks like. "If I cannot get twenty customer interviews in two weeks, I will pivot." "If fewer than 3% of landing page visitors sign up, I will rethink the positioning." "If nobody prepays after fifty conversations, this is not a business." Without a kill criteria, you will rationalise bad results indefinitely. Every founder can explain away poor numbers. The ones who succeed are honest with themselves about when to stop pushing and when to change direction. Validation is not about confirming your belief. It is about pressure-testing it.