How to validate an app idea before you spend money building it
Validating an app idea means getting proof that someone needs it before you pay to build it: talk to people who have the problem, solve it by hand for a while, show a prototype and only then build a small first version. Validation isn't people saying “great idea”, it's people doing something.
Validating an app idea means getting proof that someone needs it before you pay to build it. You do it in steps, from cheapest to most expensive: talk to people who have the problem, solve it by hand for a while, show a prototype, and only then build a small first version. At every step you can stop, change direction or keep going.
I'm telling you this from the builder's side. I'd much rather a client show up with an idea that's been tested, even a little, because then the app we build together has a far better chance of being used.
“Great idea!” doesn't count
The most common trap is asking family and friends. They love you; they're not going to say no. And even with strangers, asking “would you use an app that does this?” almost always gets a yes that costs them nothing.
What counts is action: someone leaving their email to hear when it launches, paying a deposit, using the manual version you set up, or asking you when it's coming out. One person who does something is worth more than a crowd of people who say yes.
Step 1: ask about what already happened, not what they'd do
Find people who have the problem you want to solve and ask about their recent past, not the future. Instead of “would you use an app to book tennis courts?”, ask “how did you book last time? What was the most annoying part? What do you use for it now?”
If they tell you it happened last week and they rigged up something to deal with it (a spreadsheet, a group chat, one person who handles it), you're on to something. If they struggle to remember the last time, the problem is real but may not hurt enough.
If your idea targets small businesses in a specific trade, finding people to talk to is easier than it sounds. Directories help, and if your market is Argentina, LeadsLocales, a platform I built, finds local businesses by trade and area with their public contact details.
Step 2: do it by hand before you automate it
Before there's an app, try running the service without one. If your idea connects dog walkers with owners, set up a WhatsApp number, a spreadsheet and a form, and play matchmaker yourself for a few weeks. If it's an ordering system for a trade, take orders from a handful of businesses by hand.
It's slow and it doesn't scale, and that's exactly why it works: you see up close what people ask for, where they get stuck and what they always want to know. When you turn it into an app later, you'll know what to automate first and what was never needed.
Step 3: a prototype to see if people get it
A prototype is a mockup of the app you can tap through: screens that look real and buttons that lead from one to the next, with nothing working behind them. It's quick to make and it answers one question: does someone understand what to do without you explaining it?
Sit next to someone (or share your screen), give them a task and stay quiet. Wherever they hesitate, tap the wrong thing or ask “now what?”, there's something to fix. Changing a screen in a prototype costs a tiny fraction of changing it in a finished app.
Selling before building: the idea behind Recorrido 3D
One industry lives on validating before it builds: developers selling pre-construction homes. For them I made Recorrido 3D, my own product for interactive 3D walkthroughs: buyers walk through the house or apartment on screen before it exists and decide whether to reserve a unit.
The principle is the one I'd suggest for your app: show something concrete enough that people commit, before you put in the full investment. The Recorrido 3D blog has a piece on when to order sales materials for a development that follows the same logic.
See Recorrido 3DStep 4: an MVP with a single promise
This is where real development starts. The minimum version does one thing well, whichever came through strongest in the earlier steps, and leaves the rest for later. It isn't a half-built app; it's a small app that's complete at its one job. I went deeper in what is an MVP.
What you watch at this stage isn't how many people sign up but how many come back without being nudged. If they come back, you've got something. If they don't, ask them why before adding features. There's more on that in how to keep users coming back to an app.
Signs to keep going, pivot or stop
- Keep going if people use the manual version, ask when it launches or offer to pay.
- Pivot if the problem is real but people already solve it in a way that's good enough, or if the person who suffers it isn't the one who decides.
- Stop if nobody remembers the last time it happened, or everyone says yes and nobody does anything.
Where I come in
I can work with you from step 3 on: build the prototype, watch together how people use it, then build the MVP in phases, as I describe in building software in phases. I work remotely from Buenos Aires, Argentina (UTC−3), with video calls and progress you can check through a link, and I quote each phase separately so you don't have to commit to everything upfront. More on the services page.
Frequently asked questions
Will someone steal my idea if I talk about it?
It's a common fear, but the hard part is almost never the idea. It's making it work and getting users. If it worries you, sign an NDA with your developer. What you shouldn't do is keep it to yourself and build blind.
How many people should I interview?
There's no magic number. A good sign is when answers start repeating and you can guess what the next person will say. If everyone describes a different problem, you haven't found yours yet.
Is a prototype the same as an MVP?
No. A prototype shows what the app would look like but doesn't really work; it tells you whether people get it. An MVP actually works, with very little in it, and tells you whether people use it and come back.
What if validation goes badly?
That's good news in disguise: you just avoided building something nobody would use. Often what you learned points to a different version of the idea that does have demand.
If you have an app idea and want to test it before going all in, tell me what problem it solves and who for. Message me on WhatsApp at +54 9 11 6193-3176 or email contacto@facundocampo.com.ar. I answer in English and Spanish, and we'll figure out your next step together.