Before the MVP
How to Validate an App Idea: 6 Proven Tests Before You Pay for a Build
The cheapest way to validate an app idea is to find out, before anyone writes code, whether real people have the problem, how they solve it today and whether they would change their habits for something better. This guide gives you six tests in order from cheapest to most convincing, the signals that count and the ones that only feel good, a two week plan and a scorecard to decide what to do next.
Short answer
To validate an app idea, test the problem before the product. Talk to at least ten people who have the problem, watch how they solve it today, put a clear offer on a simple landing page, deliver the service by hand to a few customers, test a clickable prototype with five users, and ask for a commitment: a pre order, a deposit or a pilot. Compliments and downloads are not validation. Money, time and changed behaviour are.
Key takeaways
- Validate the problem first. A great app for a problem nobody pays to solve is still a failure.
- Climb from cheap to convincing. Conversations cost days, a build costs months. Do them in that order.
- Look for workarounds. Spreadsheets, notes and phone calls around a problem are the strongest proof that it hurts.
- The MVP is the last test, not the first. Build when the earlier tests point the same way.
Why validate an app idea before you build it
Most first versions we see fail for the same reason, and it is rarely the code. They are built for a problem the founder assumed, with features copied from the biggest apps in the category, for users nobody spoke to before the build. The result is a polished product that answers a question nobody asked.
Validation reverses the order. You spend days, not months, checking the riskiest assumption first: that a specific group of people has this problem often enough and painfully enough to change how they work. The idea comes from the lean startup approach, but you do not need the vocabulary. You need a notebook, a list of people to call and the discipline to listen more than you pitch.
Validation does not replace an MVP. It decides what the MVP should be. When you validate an app idea properly, you arrive at the build with a narrow core flow, real first users and a number that tells you whether the product works. That is what makes the first version smaller, cheaper and much more likely to land. Our guide what is an MVP app picks up exactly where this one ends.
6 tests to validate an app idea, from cheapest to most convincing
Each test answers a different question and costs a little more than the one before. Run them in order. If a cheap test gives a clear no, you have saved the cost of every test above it.
Problem interviews
Talk to at least ten people who should have the problem. Ask about the last time it happened, what they did, what it cost them and what they tried. Do not describe your app until the end, if at all.
What it tells you: whether the problem is real, frequent and painful for a group you can reach.
Watch the workaround
Ask two or three of them to show you how they handle it today: the spreadsheet, the paper form, the group chat, the notes on the phone. A workaround is proof that the problem hurts enough to spend effort on it.
What it tells you: what the app must replace, and which step people would happily stop doing.
A landing page with a clear offer
Describe the outcome in one sentence, list three things the app will do and ask visitors to join a waitlist or book a call. Send it to the people you interviewed and to a small, targeted audience.
What it tells you: whether the promise is clear enough that strangers act on it.
Deliver it by hand
Before software, run the service manually for a few customers: take bookings by message, match people yourself, send the report from a spreadsheet. This is often called a concierge test.
What it tells you: whether people use the service repeatedly, and which steps are worth automating first.
A clickable prototype
Turn the core flow into clickable screens and ask five target users to complete the main task while you watch. Our discovery workshop often ends with exactly this kind of prototype.
What it tells you: where people get stuck, and whether the flow matches how they think about the job.
Ask for a commitment
Ask for something that costs the user: a pre order, a deposit, a signed pilot, a letter of intent, or an hour of their team's time every week during the build.
What it tells you: whether the interest survives the moment it has a price.
You do not always need all six. A business tool for your own company may stop at test two and five, because you already know the users. A consumer product with no audience yet usually needs all of them. What matters is that the decision to build rests on behaviour, not on opinions.
Real signals and false signals
The hardest part of validation is honesty with yourself. Some reactions feel like proof and mean almost nothing. Others look small and are worth more than a hundred compliments.
Real signals
- Someone pays, pre orders or puts down a deposit
- People use the manual version again without being asked
- They introduce you to a colleague with the same problem
- They show you a workaround they built themselves
- They give you time: a weekly call, a pilot, test data
False signals
- "Great idea, I would definitely download it"
- Likes and comments on a post about the idea
- Waitlist sign ups that never open a follow up email
- Enthusiasm from friends, family and investors
- A long list of feature requests with no commitment
One rule helps: count only what cost the other person something. Money, time, reputation or effort. Everything else is politeness.
Compliments are free. Validation starts at the moment someone has to give something up to use what you are building.
A two week plan to validate an app idea
For most ideas, two focused weeks are enough to know whether to move forward. Here is a plan that fits next to a full time job.
Week 1: the problem
Write the problem in one paragraph and list 20 people who should have it.
Book ten conversations. Prepare five questions about the last time it happened.
First interviews. Write down exact words people use for the problem.
More interviews. Ask two people to show you their workaround.
Sort notes: who has the problem most, how often, and what it costs them.
Week 2: the solution
Write the one core flow the app must make possible, in five to eight steps.
Publish a landing page with the outcome, three features and a waitlist.
Send it to interviewees and a targeted audience. Offer the service by hand to three.
Show sketches or a prototype to five users and watch them try the core task.
Ask for a commitment and fill in the scorecard below.
At the end of the two weeks you will have something most founders skip: a written problem, a core flow, real people waiting for the app and evidence you can show to a cofounder, an investor or a development team.
Validated the problem and ready to scope a first version? Send us your notes and we will tell you what the MVP should include and what it would take to build.
The validation scorecard
Fill this in honestly at the end of your tests. Mostly strong answers mean build. Mostly weak answers mean go back to the problem.
What to do after you validate an app idea
Scope the MVP
Turn the core flow into a written scope, fix the price and build the smallest version that makes the core action happen for your first users.
Narrow it down
One group cares a lot, the rest do not. Rewrite the idea for that group only and run the cheapest tests again.
Change the problem
Nobody would give anything up for it. Keep what you learned about the people and look for the problem they actually pay to solve.
A weak result after two weeks is a good outcome. It cost you two weeks instead of four months and a budget. When the result is strong, the next steps are covered in MVP app features, MVP app cost and, if you are building without a technical team, non technical founder.
What validation looks like in real projects
Validation does not stop when the build starts. These are moments from our projects where real users confirmed, or corrected, what the team believed.
- Real users before the public launch. On EveSport, trainers from top gyms ran sessions through the app with their own clients before the wider launch. That small group used booking, slot swapping, chat and payments for real and showed what needed fixing first. Bookings grew 18% in the first 60 days.
- Workarounds as the clearest signal. On TimeFix, before the app covered one case, technicians started writing things down in their phone's notepad. The workaround showed exactly what the next release had to include.
- Testing where the app will be used. On Liniowiec, everything worked in the simulator. Only real trips on the water showed lost connections and wrong positions on the map.
- Copying the giants. The most common planning mistake we see is a long list of features modelled on the biggest apps instead of the main value for the user. A long animated onboarding is a typical example: we replaced one with a short onboarding that asked only for the data the app really needed.
Mistakes founders make when they validate an app idea
- Pitching instead of listening. The moment you describe your solution, people start being polite. Ask about their past, not your future.
- Talking only to friends. They want you to succeed, so they say yes. Talk to strangers who have the problem.
- Treating an AI built prototype as proof. A working demo shows that the app can exist, not that anyone needs it. In founder prototypes built this way we often see a set of features with no direction behind them.
- Counting downloads and sign ups. They measure curiosity. Repeated use and payment measure value.
- Validating everything at once. Test the riskiest assumption first. Usually that is the problem, not the colour of the button.
- Skipping it because the idea feels obvious. The more obvious the idea feels to you, the more useful ten conversations will be.
If you want help turning a validated problem into a scope, a discovery workshop is usually the next step, and our MVP app development service is built for the build that follows.
About the source
Who is answering this?
- Company
- Apps Value, mobile app development agency
- Location
- Cracow, Poland
- Markets served
- United States, Western Europe, Nordics
- Experience
- 6 years, 19+ projects delivered, 13+ positive client reviews
- Projects referenced
- EveSport, TimeFix, Liniowiec
- Technologies
- Flutter, React Native, NestJS, Supabase, PostgreSQL, AWS, Google Cloud
FAQ
How do you validate an app idea?
Test the problem before the product: interview at least ten people who should have it, watch their current workaround, publish a landing page with a clear offer, deliver the service by hand, test a clickable prototype with five users and ask for a commitment such as a pre order or a pilot.
How long does it take to validate an app idea?
Two focused weeks are enough for most ideas to know whether to move forward. A manual concierge test or a pilot can add one to three weeks when you need stronger proof.
Can I validate an app idea without building anything?
Yes. Interviews, watching workarounds, a landing page, a manual version of the service and a clickable prototype all work without code. The MVP is the last validation step, not the first.
How many people should I talk to?
At least ten people who have the problem. If the same pain comes up in most conversations, in their own words, you have a strong signal. If you need to explain the problem first, the signal is weak.
Is a waitlist enough to validate an app idea?
Not on its own. Sign ups measure curiosity. Look for stronger signals: replies to follow ups, repeated use of a manual version, deposits, pre orders or a signed pilot.
What is the difference between validation and an MVP?
Validation checks whether the problem is worth solving and for whom. The MVP is the smallest working product that solves it for real users. Validation decides what the MVP should contain.
What should I do after validating my app idea?
Write down the core flow, choose who will build it, run a short discovery to fix the scope and price, and launch the first version to the people who committed during validation.
Related guides
Written by
Thomas Siudut
Co-Founder and CEO, Apps Value
Thomas sets the company's long term strategy and direction, identifies market opportunities, and owns business development and client acquisition. He works with founders from the first strategy conversation, so their business goals, not just their feature list, drive every decision.
Validated your idea? Let's scope the first version.
Send us what you learned: the problem, the people who have it and what they committed to. We will tell you what the MVP should include, what can wait, and what it would take to build at a fixed price.