You validate an app idea by getting evidence that a specific group of people will change their behaviour or hand over money for it, before anyone writes production code. A survey that returns "great idea" is not evidence. Ten conversations with people who already pay to solve the problem badly, a landing page with a real ask, and a costed scope that tells you what version one actually is - those are evidence. This article covers the four tests, the habits that produce false confidence, and how to recognise when the honest answer is not to build.
It sits alongside our broader guide on turning an app idea into a product. That post covers the whole journey. This one stops at the first decision, because it is the one most founders skip.
Validation means evidence of behaviour, not enthusiasm
Enthusiasm is cheap and it is offered freely. Every founder we meet has a folder of encouraging messages, and none of it predicts whether the product will be used. People are generous with opinions and stingy with time and money, so the only signals worth collecting are the ones that cost the respondent something.
That gives you a simple hierarchy. At the bottom is "I would use that". Above it is a stranger giving you thirty minutes to describe how they solve the problem today. Above that is an email address or a deposit handed over against a promise. At the top is someone paying for a version that does not fully exist yet. The further up the hierarchy your evidence sits, the less market research you need to do on top of it, because the market has already answered.
Test one: is the problem already being solved badly, for money?
The strongest app ideas replace something people already pay for or already spend hours on. A spreadsheet someone maintains every Sunday night, a WhatsApp group that has become a booking system, a paid tool that everyone in the industry complains about. Existing pain that is already costing time or money is the closest thing to a guarantee that demand exists.
If nobody is solving the problem at all, ask why. Sometimes it is because the technology only recently made it possible, which is a genuine opportunity. More often it is because the problem is not painful enough for anyone to act on, and an app will not change that. Write down, in one sentence, what your users do today instead of your product. If the answer is "nothing", treat that as a warning rather than an open field.
Test two: ten real conversations with the right people
Talk to ten people who match your target user and who are not related to you. Do not describe your app. Ask them how they handle the problem now, what it costs them, what they have already tried, and what they would need to see to switch. You are listening for the moment they describe the problem in stronger language than you would have used yourself. That is the signal.
Ten is not a statistically significant sample and it does not need to be. You are not measuring the market, you are testing whether the problem exists in the form you imagined. Three of the ten will usually tell you the problem is real but different from what you thought, and that correction is worth more than a hundred survey responses.
Test three: a smoke test with a real ask
Put a single page online that describes the product as though it exists, and give visitors something to do that costs them a little. A waiting list is the weakest version. A paid pre-order, a deposit, a booked demo, or a request for their current data so you can show them the result are stronger. Share it with the people from your conversations or send a little paid traffic, then measure what fraction actually act.
The point is not the conversion rate itself, which will be noisy at small numbers. The point is to find out whether anyone at all will cross the line from interested to committed. A page that gets two hundred visits and zero actions has told you something a survey never could. A clickable app prototype makes the ask more concrete and is usually enough to run this test without writing production code.
Test four: a costed scope, so you know what version one actually is
Most ideas fail validation quietly at this step, because the founder is validating a vision while the budget can only fund a fraction of it. Until version one has been scoped, you do not know what you are asking people to want. This is why our scoping and design work produces a Business Requirements Document, a Product Requirements Document, the full UX/UI design and a fixed-cost Statement of Work before any development quote exists.
The scoping exercise forces the question that validation depends on: what does the minimum viable product deliberately leave out, and does the thing that remains still solve the problem your ten conversations described? If the answer is no, the idea is not invalid, but it is more expensive than you assumed, and you now know that before rather than after. Our guide on how long an app takes to build shows how much of the timeline that scope determines.
Three habits that manufacture false confidence
- Building first. A working app feels like progress and it makes every later conversation about the app rather than the problem.
- Asking friends. People who like you will tell you what you want to hear, and they are rarely the target user anyway. Their encouragement counts for nothing in the hierarchy above.
- Reading competitors as proof or disproof. A competitor existing proves the problem is real and nothing more. A competitor not existing proves very little either way. What matters is whether their customers are satisfied, which you find out in test two.
When the honest answer is not to build
Sometimes the four tests return a clear no, and that is a successful outcome, because it cost weeks rather than a year and a development budget. We take on 5 to 10 clients per year, and recommending against building is a legitimate result of our discovery process.
When the tests return a yes, the evidence does real work. Revia reached number 3 in Apple's Health and Fitness category within 48 hours of launch after a 4-month build, and Pilates Obsession launched a full-featured Pilates platform live within 12 weeks and on budget. Both timelines depended on a tightly scoped version one, which is what validation produces. It is also what investors ask to see, which we cover in how to find investors for your app.
If you want the validation work done to a consistent standard rather than assembled ad hoc, our Idea to Insight assessment is a $497 AUD scored viability assessment of a software idea that returns a report you can share with investors or co-founders. It is deliberately independent of any build decision, so a low score is a valid and useful result.
From there the path is either a scoped MVP app development engagement or a decision not to proceed, and both are good outcomes. If you are unsure whether you need a technical partner at all, read do you need a technical co-founder. Otherwise, book a discovery call and bring the notes from your ten conversations. They are the most useful thing you can put on the table.