How to validate an app idea before you build it
Most validation advice tells you to ask people whether they would use your app. They will say yes. They are being polite, and you now have a spreadsheet full of nothing.
The problem with the usual advice
"Would you use this?" is a question about a hypothetical, asked of someone with no stake in the answer, who likes you and would rather not be discouraging. It reliably produces agreement, and agreement feels like evidence.
It gets worse when the sample is your friends and your group chat. They are answering a slightly different question, which is "do I want to be supportive of you right now", and the answer to that is almost always yes.
Building has never been cheaper, so the cost of being wrong has moved. It is not the weeks of engineering any more. It is the months you spend on the wrong thing because nothing ever told you to stop.
Measure intensity, not interest
A yes and a yes are not the same. Someone who thinks your idea is neat and someone who has been actively annoyed by this problem for a year both click the same button on a poll, and averaging them destroys the only information you had.
What you want is a scale with real weight at the top, so that mild approval cannot masquerade as demand. Ask people to say how strongly they want it, not whether they want it. Then look at the distribution rather than the average.
Go beyond likes. Measure how strongly people want your idea, from casual interest to strong conviction.
Ten people who mildly approve is a worse signal than two who want it badly, because the two will tell you what to build and the ten will not tell you anything. A handful of strong reactions beats a broad shrug.
Ask people who will actually tell you
Signal quality is mostly a function of who you asked. In rough order of usefulness:
- People who currently have the problem and have already tried to solve it badly. They will tell you what is wrong with your idea in the first thirty seconds.
- People who work adjacent to it. They know the constraints you have not hit yet.
- Strangers with no social stake. Harder to reach, considerably more honest.
- Your friends. Useful for finding out whether the idea is legible. Not useful for finding out whether it is wanted.
Lower the cost of answering as far as it will go. Anything that needs an account, a login, or a scheduled call filters your responses down to the people who like you most, which is the opposite of what you want. A link someone can open, react to, and close in fifteen seconds gets you a different and better sample.
Collect the objections, not just the verdict
The score tells you whether to keep going. The comments tell you what to build. Of the two, the comments are worth more, and they are the part people forget to keep.
Three kinds are worth chasing down:
- The feature you did not think of. Usually phrased as an offhand "could it also". These are the highest value thing anyone will give you.
- The reason it will not work. Cheaper to hear now than to discover in month three. If two different people raise the same objection unprompted, that is a real constraint, not a personality.
- The wrong summary. When someone plays your idea back to you incorrectly, your description is broken, not their comprehension. Fix the words before you fix the product.
Do not let the findings evaporate
This is the step almost every validation guide misses. People run a decent process, learn several real things, and then start building from memory a week later. The validation and the build are disconnected, so the evidence quietly stops mattering.
Whatever you learn needs to end up in the thing you build from. If you are handing the work to an AI coding agent, that means it belongs in the specification, not in a document nobody opens again:
- Strong reactions become core features. Weak ones become enhanced, or get cut.
- Repeated objections become constraints.
- The way people described the problem back to you becomes your purpose and audience sections.
- The feature requests you did not think of become the roadmap.
Done this way, validation is not a gate you pass before the real work. It is the raw material the real work is made of.
Signals that are not signals
- Likes and reshares. Measures how well the idea presents, not whether anyone needs it.
- Waitlist signups with no friction. A free email address costs nothing, so it proves nothing.
- "I would definitely pay for that." Would and did are different verbs.
- Any sample under five where everyone agreed. That is not consensus, that is a small room.
A workable loop
- Write the idea down properly. Title, description, who it is for. One paragraph, not one line.
- Share it as a link with people who have the problem. No account, no friction.
- Ask for strength of interest rather than a yes or no, and watch the distribution.
- Chase the comments harder than the score.
- Fold what you learned into the specification you will build from.
- Build the core, ship it, and go again.
How idz does this. idz gives every idea a shareable card with a public link that needs no account, collects conviction votes rather than likes, and keeps the comments and feature requests attached to the idea. When you generate a specification, it is synthesized from all of that, so what people told you ends up in what your agent builds.