# How to validate a startup idea before you build anything

Source: https://hypothis.ai/blog/how-to-validate-a-startup-idea
Published: 2026-06-02
Updated: 2026-10-09
Author: Kapil Hingu

Most advice about how to validate a startup idea falls into one of two camps. Build a minimum viable product and see what sticks, or talk to a dozen friends who tell you it's brilliant. Neither works. Building burns months you can't get back if the idea is wrong, and friendly feedback is mostly politeness.

Real validation is narrower and more useful than either. You write down specific, falsifiable claims and test them against people who are under no obligation to be kind to you. You can do that on your own, in weeks, without code.

## What "validation" means

Validation is a test that can fail. If your process can't produce the result "this isn't working," you're performing a ritual on the way to building what you'd already decided to build.

A useful validation process has three parts:

1. **Claims:** specific statements about your customer that could turn out to be false.
2. **Evidence:** reports of real behavior from people in your target segment.
3. **A verdict:** a read on which claims held up, which broke, and what that means for your next move.

Drop any one and the process falls apart. Claims without evidence give you a business plan. Evidence without claims gives you a pile of transcripts. Claims and evidence without a verdict is homework you never graded.

## Step 1: Turn the idea into hypotheses

Before you ask anyone anything, write down what has to be true for this idea to work. "People will love this" can't be tested. Break it into separate claims you can check:

### The five claims worth testing separately

- **Problem:** people in your segment experience this problem, and it hurts enough to act on.
- **Willingness to pay:** they would pay at least a specific amount, and that compares well with what they already spend on workarounds.
- **Behavior:** they would actually change what they do to adopt this, as opposed to saying they would.
- **Solution fit:** your specific approach beats the tool or workaround they use today.
- **Market:** the segment is large enough, and it's the right one to start with.

If you test these as one bundled question, you can't read the result. An idea can pass on problem and fail on price, and "real problem, wrong price point" sends you somewhere very different from "no real problem at all." Keep them separate. I go deeper on this in [how to write a startup hypothesis](/blog/writing-testable-hypotheses), with worked [startup hypothesis examples](/blog/startup-hypothesis-examples) for each area.

### Write the failure condition first

For each claim, write down the result that would prove it false before you collect any data. "Nobody in the segment currently spends meaningful time or money on this problem" is a real failure condition you can write down. If you can't describe a plausible "no" for a claim, it's still too vague to test.

## Step 2: Recruit people who aren't rooting for you

Friends and family want you to succeed, so kindness bends their feedback. You need people who fit the target segment and have no personal stake in your feelings.

A screener question at the start of your research does more for quality than extra sample size. It filters out people who don't have the problem, so their answers don't dilute the signal from people who do. One good screener beats fifty extra unscreened responses.

Where you find them depends on the segment: relevant subreddits, Slack or Discord communities, LinkedIn searches, niche newsletters, or a recruiting panel if you have a small budget. Aim for 10 to 20 qualified responses per round. That's enough to see a pattern without drowning in data.

## Step 3: Ask about behavior

"Would you use this?" gets a yes almost every time, because saying yes costs the respondent nothing. Ask about what they've already done.

### Questions that test something

- "What do you use to handle this today?"
- "When did you last run into this problem? Walk me through what happened."
- "What have you paid, in money or hours, trying to solve this?"
- "What would have to change for you to switch away from your current approach?"

Past behavior predicts future behavior far better than a hypothetical opinion. This discipline comes from Rob Fitzpatrick's *The Mom Test*, and it's harder to stick to than it sounds when you wrote the questions yourself. [Applying the Mom Test when you don't have a research team](/blog/mom-test-for-solo-founders) covers the common traps and how to rewrite around them.

## Step 4: Read the evidence honestly

Once responses are in, score each hypothesis against what people actually reported: confirmed, weakened, or inconclusive. Then roll those up into one read on the idea.

### Signs the evidence is telling you to stop

- People describe the problem as mildly annoying.
- Nobody currently spends money or real effort on a workaround.
- People say they'd use it but can't point to a recent moment when they needed it.
- Willingness to pay is entirely hypothetical, with no adjacent spend.

One of these on its own isn't fatal. Several together, across enough respondents, is a pattern. A clean, early "no" is the most useful thing validation can give you, because it hands back the months you would have spent building. There's more on that in [when to kill a startup idea](/blog/when-to-kill-your-startup-idea).

## A realistic timeline

| Week | Work |
|---|---|
| 1 | Write hypotheses and failure conditions. Draft screener and questions. |
| 2 | Recruit and send. Collect responses. |
| 3 | Score hypotheses. Write the verdict. Decide: build, refine, keep testing, or stop. |

I'd take three weeks to a decision I can trust over six months building a product nobody asked for.

## Common questions

### How many people do I need to talk to?

For a single research round, 10 to 20 qualified respondents is usually enough to see whether a pattern exists. Fit matters more than volume: five people who really have the problem tell you more than fifty who don't. More detail in [how many customer interviews you need before building](/blog/how-many-customer-interviews).

### Can I validate an idea with an AI tool instead?

An AI can sharpen your hypotheses and draft unbiased questions. It can't tell you whether your specific customer has the problem this week, because it hasn't talked to them. Use AI to build the instrument and real people for the evidence. See [why an AI can't validate your startup idea by itself](/blog/ai-validators-vs-real-research).

### What if I've already started building?

Run the research anyway. Confirming a weak idea now costs a few weeks. Finding out after launch costs everything you built in between.

### Isn't a landing page test enough?

A landing page measures whether a message earns a click. That's useful, but it doesn't confirm the problem is painful or that people will pay. Treat it as one input among several.

## Run this on your own idea

Hypothis is built around this loop. Describe your idea and it becomes a falsifiable hypothesis set. Hypothis then builds the research instrument with screeners and Mom-Test-disciplined questions, collects responses from real people you recruit, and gives you an honest verdict: build it, refine it, keep testing, or walk away. It's free during early access. [See how it works](/how-it-works) or [create your account](/register).