How to check an app idea before you build it

Short answer

Check four things, in this order: that the problem keeps happening, that people already look for a way out of it, that the apps they use leave something unsolved, and that you wrote down beforehand what result would make you drop the idea.

Most app ideas aren't tested — they're defended. Someone describes a feature, a few people say it sounds useful, and that agreement gets treated as demand. Agreement costs nothing. Building costs months.

A useful check works in reverse. Instead of hunting for reasons the idea is good, you hunt for the cheapest observation that would show it's wrong. If you can't think of one, the idea isn't specific enough to test yet.

Describe the problem without naming a feature

Write down who has the problem, in what situation, and what they want to end up with. No screens, no features, no technology yet. "People want a habit tracker" is a feature. "Someone two weeks into a new routine can't tell whether anything is improving" is a problem you can go looking for evidence of.

The test is simple. If your description fits twenty apps that already exist, you've described a category, not a problem. Education alone holds about 285,000 live apps on the US Play Store, and another 118,000 on the App Store, so "an app for learning" describes a shelf, not a situation. Categories can't be validated. Situations can.

Collect several independent kinds of evidence

One source is never enough, because each one is biased in its own predictable way:

Search behaviour shows what people try to solve alone, but only in words they already know. New categories are invisible here.
Reviews of existing apps show what breaks in practice, though they over-represent users with strong feelings: delighted or furious, rarely indifferent. And for much of the market there is nothing to read: close to half of US App Store apps have no reviews at all.
Category movement shows whether demand is growing or a market is consolidating, but not why. Growth is also the background rather than the signal: over a recent ten-week stretch, the median US app added around 4% installs.
Interviews give you reasoning and context, but people are unreliable narrators of their own future behaviour.

Evidence convinces when different kinds of it point the same way. Four interviews aren't four sources; they're one source repeated four times.

Look at alternatives, not just competitors

Your real competitor is usually not another app. It's a spreadsheet, a notes file, a group chat, a paper list, or doing nothing at all. If people already handle the problem with a notes file and feel fine about it, the gap you're aiming at may not hurt enough to move anyone.

It's worth checking whether the competition is still breathing, too. More than 400,000 apps on the US store have gone six months or longer without an update, so a good share of any results page is abandoned work that looks like competition and isn't.

The question worth asking isn't "is there an app for this?" It's "what happens today when this problem comes up, and what does that cost the person?"

The strongest signal is not that people want your solution. It is that they already built a worse one themselves.

Decide the decision rule before you look

Write down, in advance, what you expect to find and what you'll do in each case: keep going, change the hypothesis, or drop it. Doing this afterwards isn't a decision, it's an interpretation — and interpretation always favours the idea you've already fallen for.

The rule can be blunt. "If the top complaints about existing apps are about price rather than the workflow, my premise is wrong and I stop." What matters is that it exists before the evidence does.

Limits of this approach

Validation lowers uncertainty; it doesn't produce certainty. Public data describes categories that already exist far better than ones that don't, so genuinely new ideas will always look weaker on paper than incremental ones. The store splits into roughly 11,600 clusters of similar apps, and only about 4,700 of them hold enough products to support any statistics at all. And none of it measures execution: two teams can start from the same validated problem and end up nowhere near each other.

The goal isn't to prove the idea is good. It's to make the mistake cheap if it isn't.

Figures come from our own dataset of the US catalogues: Google Play, measured in late May and early August 2026, and the App Store in May 2026.