Validate an app idea by proving three things before you build: people search for the problem, existing apps leave a gap, and some users will commit, by signing up, pre-registering or paying. Use app store search and competitor reviews for demand, interviews for the problem, and a landing page, clickable prototype or pre-registration for commitment. Build only when the evidence points the same way.
What validation has to prove
An app idea is worth building when a specific group of people has a frequent, painful problem, current solutions disappoint them, and they will take action to get something better. Compliments from friends prove none of these.
Treat validation as a short set of experiments with pass and fail criteria written down in advance, so you cannot talk yourself into a weak result later.
Test 1: store search demand
Type your problem into App Store and Google Play search and note the autocomplete suggestions, which reflect what people search. Check how many apps rank and how established they are. Our guide to store search autocomplete explains how to read suggestions.
Add a keyword tool to estimate popularity and difficulty, as covered in keyword popularity and difficulty scores.
Test 2: competitor reviews
Read the one- to three-star reviews of the top five competing apps. Repeated complaints are the gaps your app could fill: missing features, confusing pricing, bugs or poor support.
Our guide to mining reviews for keywords shows how to turn review text into both product insights and store keywords.
Test 3: problem interviews
Talk to ten to fifteen people in your target group about how they handle the problem today. Ask about the last time it happened, what they tried and what it cost them. Avoid pitching your idea until the end.
If people cannot remember the last time the problem happened, it is probably not painful enough to change their behaviour.
Test 4: landing page and waitlist
Build a one-page site that describes the app’s main benefit and asks visitors to join a waitlist. Send a small amount of targeted traffic from search or social ads and measure the sign-up rate.
Write the page the way you would write your store listing: benefit-led headline, three key features and proof. That copy becomes your first store description.
Test 5: clickable prototype
A clickable prototype made in a design tool lets people try the main flow without any code. Watch five to eight people use it and note where they hesitate.
This tests usability and value at the same time, and it is much cheaper to change a prototype than a built app.
Test 6: pre-registration and pre-orders
Google Play pre-registration and App Store pre-orders let users commit before launch. A healthy pre-registration count from a modest promotion is strong evidence. Our guide to Google Play pre-registration covers setup.
Pre-registered users also get notified at launch, which gives you an early install spike.
Tests 7 to 9: concierge, pricing and smoke tests
A concierge test delivers the service manually to a few users before automating it. A pricing test asks people to choose a plan or pay a deposit. A smoke test runs ads for an app that does not exist yet and measures clicks on a “get the app” button.
Each test answers a different question, so pick the ones that address your riskiest assumption first.
Read the results honestly
Compare results with the thresholds you wrote down. If demand is weak in search but strong in interviews, the problem may be real but people do not know to search for it, which means marketing will cost more.
When the evidence is positive, build the smallest version that solves the core problem, then follow our pre-launch ASO strategy.
Size the market before you build
Estimate how many people have the problem and how many you could realistically reach. Use store keyword popularity, category charts and the review counts of competing apps as rough signals: an app with hundreds of thousands of ratings shows a large, active audience. A small market can still work if users value the app highly and will pay for it.
Write the numbers down next to your validation results. A strong test result in a tiny market and a weak result in a huge market call for different decisions.
Signals that an idea is weak
Watch for interviews where people describe the problem as mildly annoying, landing pages that attract clicks but no sign-ups, and competitors whose reviews are mostly positive. Each suggests the gap you hoped to fill may not exist.
Weak signals are useful. They tell you to change the audience, narrow the problem or rethink the solution before spending on development.
A worked example: a meal-planning app
A founder wants to build a meal-planning app for busy parents. Store autocomplete shows steady searches for meal planner and grocery list terms, and competitor reviews complain about recipes that take too long and shopping lists that do not sync between partners.
Twelve interviews confirm that weeknight planning is a weekly frustration. A landing page promising fifteen-minute family meals with a shared list converts well from parenting groups, so the founder builds a small first version focused on those two features.
How to do it, step by step
- Write your riskiest assumptionName the belief that would kill the idea if it were wrong.
- Check store demandUse autocomplete, rankings and keyword tools.
- Mine competitor reviewsList repeated complaints in low ratings.
- Run a commitment testWaitlist, pre-registration or a paid deposit.
- Decide with thresholdsCompare results with pass criteria set in advance.
Before and after examples
Illustrative examples written for a generic app in this category, not client results. Swap in your own product, audience, and data.
Friends said they would use it.
120 waitlist sign-ups from 2,000 targeted visitors.
Why it works: Action beats opinion.
Would you use an app that does X?
Tell me about the last time you had this problem.
Why it works: Past behaviour predicts future behaviour.
Counted competitors.
Listed the top complaints in their 1–3 star reviews.
Why it works: Complaints reveal gaps.
Action plan
- Name the riskiest assumption
- Research store demand
- Read competitor reviews
- Interview real users
- Run a commitment test
- Decide with written thresholds
Metrics to monitor
- Waitlist conversion rate
- Pre-registrations
- Interview problem frequency
- Prototype task completion
- Willingness to pay
Record the baseline, release date, audience, markets, and external changes before interpreting movement. Rankings and conversion are useful signals, but a decision is stronger when activation, retention, and business value confirm that the page attracted the right users.
Frequently asked questions
How long does app idea validation take?
Two to six weeks is typical for interviews, a landing page and a prototype test.
How much does validation cost?
Often very little: a landing page, a small ad budget and your time.
What is a good waitlist conversion rate?
It varies by traffic source. Compare against your own written threshold and look for consistent interest from targeted visitors.
Should I worry if there are many competitors?
Competition proves demand. Look for gaps in their reviews and a specific audience they serve poorly.
Can I validate with app store data alone?
Store data shows demand, but combine it with interviews and a commitment test for a reliable answer.
What if validation fails?
Change the audience, the problem or the solution and test again before building.
Keep reading
Go deeper on this topic
More in Launch and Growth
Browse all 11 Launch and Growth guides
