Most apps do not fail because they were badly built. They fail because nobody needed them enough to download, learn and keep using them. The good news is that you can find this out cheaply — in weeks, for a fraction of a development budget — before a line of code is written. This guide gives you a practical, step-by-step way to validate an app idea: define the problem, talk to real people, size the demand, study alternatives and test a prototype, then decide with evidence rather than excitement.
In this article
Why validate first?
Building is the most expensive way to learn whether an idea works. Validation inverts the order: learn first, build second. Even a few weeks of structured testing can save months of effort — or confirm that you are onto something and sharpen exactly what to build. If you do decide to build, validation also gives your development team a far clearer brief, which lowers cost and risk (see our guide to what mobile apps cost).
- 1
Define the problem
Who has it, how often, how painful?
- 2
Talk to users
Interview 10–20 people about past behaviour.
- 3
Check alternatives
What do they use today, and why is it not enough?
- 4
Test a prototype
Show a clickable version or run it manually.
- 5
Measure real intent
Sign-ups, deposits, pilots — not compliments.
- 6
Decide
Proceed, pivot or stop, against criteria you set in advance.
Step 1: Write the problem down
Complete this sentence in plain language. If you cannot, the idea is not ready to test yet.
- Specific beats general. “Independent physiotherapists who lose income to no-shows” beats “health professionals”.
- Frequency matters. A problem faced daily is a better app candidate than one faced yearly.
- Pain you can measure (hours, money, errors) makes a stronger case than mild inconvenience.
Step 2: Interview real people
Aim for 10–20 conversations with people who genuinely have the problem. The goal is to learn, not to pitch. The most useful questions are about the past, because people are poor predictors of their own future behaviour.
Ask this
- “Tell me about the last time you had to [do the task].”
- “What did you try to fix it? What did that cost?”
- “What would happen if you did nothing?”
- “How do you decide what to use for this today?”
Not this
- “Would you use an app that does X?”
- “Do you like my idea?”
- “Would you pay for this?” (people are polite)
- “What features would you want?” (they will invent a wish list)
What to listen for
- Stories where the problem cost real time or money.
- Workarounds they built themselves (spreadsheets, group chats, paper).
- Words they use to describe the problem — reuse them in your marketing.
- Patterns: the same pain from several unrelated people is a strong signal.
Step 3: Study the alternatives
Competitors are good news: they prove demand. The warning sign is a market with no alternatives and no workarounds, which often means nobody cares enough. Map what people use today — apps, spreadsheets, agencies, doing nothing — and write one line on why each falls short.
| Alternative | Who uses it | What they like | Where it falls short |
|---|---|---|---|
| Direct competitor app | Early adopters | Familiar, polished | Expensive / too generic / missing a key feature |
| Spreadsheet or paper | Small teams | Free and flexible | Manual, error-prone, hard to share |
| Hiring a person or agency | Larger organisations | Handles exceptions | Slow and costly |
| Doing nothing | Everyone else | No effort | Problem remains |
Step 4: Test with a prototype or a manual version
You can test the solution without building it:
- Clickable prototype: designers can build a realistic one in days. Put it in front of users and watch where they hesitate.
- Concierge version: deliver the service by hand (spreadsheets, messages, calls) to a few customers to learn what really matters.
- Landing page test: describe the app, show mock-ups and measure sign-ups or enquiries.
- Pilot with one customer: nothing validates like someone using a basic version in their real work.
Step 5: Decide — proceed, pivot or stop
- Several people described the problem unprompted and in detail
- They already spend time or money on workarounds
- You can reach this group affordably
- Prototype testers completed the main task and asked when it would be ready
- At least some people gave real commitment (deposit, pilot, introduction)
- You can describe a smallest useful first version
If the signals are strong, move to defining a minimum viable product and a scoped brief, then follow the process in the mobile app development process. If they are weak, pivot the problem, the audience or the solution — or stop and keep your budget. Either outcome is a win compared with building blind.
Frequently asked questions
Check that a specific group has a frequent, painful problem, already spends time or money on workarounds, and shows real commitment to a prototype or pilot. Evidence of behaviour matters more than enthusiasm.
Get the next guide in your inbox
One useful article on apps, software, AI and automation when we publish. No spam, unsubscribe any time.
We use your email only to send these guides. See our privacy policy.
Ready to talk it through?
Tell us what you’re planning and we’ll give you an honest recommendation — no pressure, no jargon. You can also explore our mobile app development services.
