How to Validate an iOS App Idea Before Building
Asking whether people like your idea is free for them to answer, which is exactly why the answer is worthless.
Short answer
Validate an iOS app idea by finding whether people already spend money or effort solving the problem, not by asking whether they like the concept. The sequence that works: talk to fifteen people about what they do today, deliver the outcome manually for a handful of them, put up a page that asks for a real commitment, and only then build the smallest version that delivers value. Each step costs days rather than months and answers a question the next step depends on.
Why the usual validation fails
Asking people whether they would use your app produces useless data, because saying yes is free and polite. The same person who enthused for ten minutes will not install it, and you will not find out for six months.
Surveys have the same defect at scale. A hundred people saying they would pay 5 a month tells you almost nothing about whether anyone will pay 5 a month, since the question costs nothing to answer.
Friends and family are the worst possible sample. They are selected for wanting you to succeed, and they will not say the thing you need to hear.
What produces reliable signal is behaviour: what someone already does, what they already pay for, what they are already working around. Behaviour has costs attached, which is exactly what makes it informative.
| Weak signal | Strong signal |
|---|---|
| ”That sounds useful" | "When can I have it?” |
| Survey responses | A workaround they built themselves |
| Friends encouraging you | A stranger paying for the manual version |
| Sign-ups for a free list | A deposit, a card, or a scheduled call |
| Competitor exists, so demand exists | Competitor’s customers complaining specifically |
The four steps, in order
Step one: fifteen conversations. Find people with the problem and ask what they did the last time it came up. Ask what it cost them, in money or time. Ask what they use instead. Do not describe your app until the end, because once you do, the conversation becomes about your idea rather than their situation.
Step two: do it manually. Whatever your app would automate, do it by hand for five people. A spreadsheet, a shared inbox, an evening a week. This proves the value is real and teaches you the workflow in detail no interview would surface.
Step three: ask for a commitment. A landing page describing the product with a way to say yes, and traffic from wherever these people already gather. The commitment should cost something: a deposit, a card on file, a scheduled call, a pre-order. Email addresses are cheap and weakly predictive.
Step four: build the smallest version that delivers the value, and put it in front of the people from step three. TestFlight makes this easy for a small group, and watching five people use the app without helping them is worth more than any amount of analytics at this stage.
What “smallest version” actually means
It means one job, done properly, for one kind of person. Not a stripped version of the whole vision: the single most valuable thing, built well enough that using it is pleasant.
That distinction matters because a thin version of everything teaches you nothing. If someone abandons it, you cannot tell whether the idea is wrong or the execution was. One job done well produces a clean answer.
The temptation to add is strongest here, and every addition delays the answer you are paying for. Keep the second list, put everything on it, and revisit after real usage.
Reading the results honestly
The hardest part of validation is not running it, it is interpreting it without flattering yourself, and two failure patterns show up repeatedly.
The first is hearing agreement where there was none. Someone says “yes, that is a real problem” and the founder records a validated user; what the person actually said is that the problem exists, which was never in doubt. The question that separates the two is whether they have done anything about it. A person who built a spreadsheet, hired someone, or pays for a bad alternative has voted with effort. A person who agrees has voted with politeness.
The second is treating a small number of enthusiasts as a market. Every idea has early enthusiasts, including bad ones, and their enthusiasm is a necessary but weak signal. What upgrades it is whether they are recognisably similar to each other: fifteen people with the same job, the same workflow and the same trigger describe a market, while fifteen people who each love a different aspect describe a product with no centre.
A useful discipline is to write down, before each round, what result would make you stop. Founders who skip that step find a reason to continue regardless of what they hear, which makes the whole exercise expensive theatre.
What validation cannot tell you
It cannot tell you the market is large enough. Fifteen enthusiastic people prove the problem is real and say nothing about whether fifteen thousand exist, which is a separate question answered by market sizing.
It cannot tell you the economics work. That is arithmetic: what a customer pays, what acquisition costs, how long they stay, and, for digital goods on iOS, Apple’s commission of 30 percent or 15 percent for most small developers under the App Store Small Business Program.
It also cannot tell you the timing is right. Plenty of good ideas were validated correctly and failed because the market was three years early, and no amount of user research surfaces that, since the people you interview live in the present too. And it cannot tell you whether you will keep going. Founder persistence is not validated by research, and a validated idea with a founder who loses interest in month four fails exactly like an unvalidated one.
| Step | Time | What it proves |
|---|---|---|
| Fifteen conversations | One to two weeks | The problem exists and costs something |
| Manual delivery for five | Two to four weeks | The value is real, and how the work runs |
| Commitment page | One to two weeks | People will act, not just approve |
| Smallest real version | Six to twelve weeks | People use it repeatedly |
When to stop validating and build
When the same problem comes back in a form you can describe in one sentence, when people have paid for the manual version or committed something to get it, and when you can name who the first hundred users are and how they will hear about it. That combination is enough. Waiting for certainty is its own failure mode, because certainty does not arrive before you ship.
Conversely, three signals say stop or change direction: nobody will pay for the manual version, everyone describes a slightly different problem, or the people who like it most are not the people who would pay.
The third of those is the subtlest and the most common in consumer products. Enthusiasm concentrates in people who enjoy the category, and payment concentrates in people who have a costly problem, and those two groups overlap less than founders assume. When they diverge, the honest options are to change who the product is for or to change how it makes money, and continuing on the assumption that enthusiasm converts is how a validated idea still runs out of runway.
Doing it without lying to yourself
Two practical habits keep a validation exercise honest.
Record the conversations, with permission, or write notes within an hour. Memory reshapes what people said toward what you hoped they said, and the effect is strongest for the conversations you cared about most. Notes written a week later are a summary of your own optimism.
Have someone else run three of the fifteen conversations. A founder cannot help selling, even while trying not to, and the difference between how people talk to the founder and how they talk to a neutral interviewer is often the whole finding.
A third habit is worth it if the idea is expensive: write the case against it. One page arguing why this will not work, taken seriously enough that a sceptical friend would sign it. Ideas that survive that document are meaningfully more likely to survive the market, and ideas that cannot are cheaper to abandon on paper.
Where this approach does not work
Some ideas resist cheap validation. Two-sided marketplaces are useless below a threshold on both sides, so a manual version is genuinely hard and the honest path involves picking one geography or one narrow niche. Regulated products may need a licence before you can legally deliver the outcome at all. And infrastructure products, where the customer is a developer or a business system, validate through pilots and integration commitments rather than through consumer-style tests.
If you have an idea and want help working out the cheapest honest test for it, book a free app idea call and we will tell you what we would try first, including when the answer is that you should not build yet.
FAQ
How do I validate an app idea before building it?
Four steps. Talk to fifteen people about what they did the last time the problem came up and what it cost them. Deliver the outcome manually for five of them with a spreadsheet and your own hours. Put up a page asking for a commitment that costs something, a deposit, a card or a scheduled call. Then build the smallest version that delivers the value and put it in front of those people.
Why is asking people about my app idea unreliable?
Because saying yes is free and polite. The same person who enthused for ten minutes will not install the app, and you will not discover that for months. Surveys have the same defect at scale, and friends are the worst sample because they are selected for wanting you to succeed. Behaviour has costs attached, which is exactly what makes it informative.
What is the smallest version I should build?
One job, done properly, for one kind of person, rather than a thin version of the whole vision. That distinction matters because a thin version of everything teaches you nothing: if someone abandons it, you cannot tell whether the idea was wrong or the execution was. One job done well gives a clean answer, and everything else goes on a later list.
How long should validation take?
Roughly four to eight weeks before any build. One to two weeks of conversations, two to four weeks delivering the outcome manually, and one to two weeks running a commitment page. The build that follows takes months, which is precisely why the weeks spent first are worth it. Waiting longer than that is usually avoidance rather than research.
When should I stop validating and start building?
When the same problem keeps coming back in a form you can state in one sentence, when people have paid for or committed something to get the manual version, and when you can name who the first hundred users are and how they will hear about it. Certainty never arrives before shipping, so waiting for it is its own failure mode.