How to validate an app idea before you build
Validation is the cheapest insurance you can buy. Here are the tests that tell you whether an idea has legs, none of which require writing production code.
You validate an app idea by confirming that a specific group of people has a problem painful enough to change their behavior for — and will act — before you write any code. The four cheapest ways to learn that are problem interviews, a landing-page smoke test, a clickable prototype, and asking for a small commitment. None require a build, and together they can tell you in a week whether an idea is worth funding.
Validation isn't asking people if they like your idea. It's checking whether strangers will give you their time, their email, or their money to solve the problem.
What validation actually proves
Validation exists to separate real demand from politeness. Friends, family, and even prospective users will tell you an idea is great because being encouraging is easier than being honest. That feedback feels like progress and proves nothing. Real validation looks for behavior — a signup, a deposit, a completed task in a prototype — because behavior is expensive to fake and opinions are free.
The three things you are trying to confirm: the problem is real and painful, your ICP is the group that feels it most, and your solution is something they would actually adopt over what they use today.
Method 1 — Problem interviews
Talk to people in your target ICP about the problem, not your solution. The goal is to understand how they experience the pain today, what it costs them, and what they've tried. Ask about the past ("walk me through the last time this happened") rather than the future ("would you use an app that…"), because people are accurate historians and terrible predictors.
How to keep interviews honest
- Ask about specific past events, not hypothetical future behavior.
- Don't pitch — the moment you describe your app, they start being polite.
- Listen for whether they've already tried to solve it. People who've cobbled together a workaround have real pain.
- A handful of focused conversations often reveals the pattern; you're looking for a repeated story, not a statistically significant sample.
Method 2 — The landing-page smoke test
Put up a single page that describes the solution as if it exists, with one clear call to action — join the waitlist, request early access, get notified. Then drive a little traffic to it and measure how many people convert. A landing page tests demand for the solution the way interviews test the problem: it turns interest into a measurable action. The signup rate, and the words people use when they sign up, tell you whether the promise lands.
Method 3 — The clickable prototype
A clickable prototype — screens linked together without any code behind them — lets you put the actual experience in front of people and watch what happens. You're testing two things: whether they understand the core value, and whether they can reach it without getting stuck. Watching five people attempt the core task, in silence, reveals more about your UX than any survey. If the value is buried or the flow confuses them on paper, it will confuse them in the built app too.
Method 4 — Ask for commitment
The strongest pre-build signal is a small sacrifice. A pre-order, a refundable deposit, a paid pilot, or even a firm scheduled call is worth more than a hundred "I'd definitely use that" comments, because it costs the person something. A concierge approach — delivering the outcome manually, behind the scenes, before automating it — is another way to prove people will pay for the result before you build the machine that produces it.
Real signals vs vanity signals
Not all positive feedback means the same thing. Learn to weight it:
- Real signals — a stranger's email, a deposit, a completed prototype task, an unsolicited "when can I have this?", a description of a painful current workaround.
- Vanity signals — "great idea," social likes, a friend's encouragement, a large but unengaged waitlist, agreement to a leading question.
The test: did it cost the person anything to give you this signal? The more it cost them, the more it means.
Proceed, pivot, or stop
Validation is only useful if you'll act on it. Strong signals across methods mean proceed to scoping and a PRD. Mixed signals — real problem, wrong solution or wrong ICP — mean pivot: keep what validated and change what didn't. Consistently weak signals mean stop, or reshape the idea, before you spend a build budget proving the same thing the hard way. Killing or reshaping a weak idea in week one is not failure; it is the entire point, and the cheapest win validation can deliver. This work is the first step in planning an app.