How to Validate an App Idea Before You Write Code
To validate an app idea before you write code, you find real people who have the problem, confirm they hate it enough to want a fix, then get them to take a costly action toward a fake or manual version of your app, all before you build the real thing. Validation means proving strangers actually want your app, not asking them if they think it sounds cool. If you skip this, you can burn three months coding something no one opens.
Here is the trap almost every first-time founder falls into, and it is easy to fall into because it feels like progress: you get an idea, it feels obvious and great, and your brain jumps straight to building. Screens, features, a name, a logo. Coding feels like real work. But at that stage you have zero evidence anyone wants the thing. You are just decorating a guess. This post is the cheaper path.
Why coding first is the most expensive mistake you can make
An app is one of the slowest, most expensive ways to test whether an idea works. Even with modern tools, a real app takes weeks to build, breaks constantly, and can only tell you one thing at a time. Meanwhile your assumption, the belief that people want this, is still totally untested.
So when you code first, you spend your rarest resource, time, on the part that matters least. You end up emotionally attached to something you have poured a semester into, which makes it painful to hear the truth later. The whole point of validation is to get the “no” cheap and early, while it still costs you a weekend to change your mind instead of a semester.
Building an app is where you go once you know people want it. Validation is how you earn the right to build. Doing it in that order is not being cautious; it is the fastest route to an app people actually use, because you are not wasting the build on a guess.
What does it actually mean to validate an app idea?
Validating an app idea means gathering real-world evidence that answers three questions in order, before you commit to building.
- Is the problem real? Do actual people have this pain, and do they have it often and badly enough to care?
- Do they want it solved? Are they already trying to fix it with duct-tape workarounds, or do they just shrug and live with it?
- Will they act? When you put something in front of them, do they sign up, click, or pay, or do they just say “nice” and walk away?
Notice what is not on that list: “Does my mom think it is a good idea?” and “Do my friends say they would use it?” Those feel like validation but they are not. People who like you tell you what you want to hear. That is exactly why “my friends love it” is not real validation. Real validation comes from people who owe you nothing and still take action.
The cheap tests you run before you build anything
You do not need code, money, or a co-founder for any of this. Here is the toolkit, roughly in order, from talking to people to making them commit. Each one is a lever you can pull in a weekend.
| Test | What it answers | Time and cost |
|---|---|---|
| Customer interviews | Is the problem real and painful? | A few hours, free |
| Competitor scan | Are people already paying to solve this? | An afternoon, free |
| Landing page | Does the idea itself grab strangers? | A weekend, ~$0 to $15 for a domain |
| Fake door test | Do people click toward a product that doesn’t exist yet? | A weekend, free |
| Concierge MVP | Will people accept the outcome if you do it by hand? | A week, mostly your time |
| Pre-sell | Will people actually pay before it exists? | A week, free |
Start at the top and only move down as each one passes. Here is how to run the first few, which do most of the work.
Talk to people who have the problem. Before anything else, find 10 to 15 people who live with the pain your app would fix and interview them. Not about your app, about their life. If you are building a study app, ask a classmate to walk you through the last time they crammed for a test: what they used, where it fell apart, what they wished existed. The beginner’s guide to customer interviews shows exactly how, and the Mom Test is the trick for getting honest answers instead of polite ones. The rule: ask about their past behavior, never about your future product.
Scan who already solves this. Spend an afternoon finding every existing app, tool, or hack people use for this problem. If nothing exists, that is a warning, not a green light, because it often means there is no money in it. If competitors exist and people pay for them, that is proof the problem is real and you just need a better angle. Do this without spiraling using how to do competitive analysis without overthinking it.
Build a landing page, not an app. A single web page that describes your app as if it exists, with one button, is the fastest way to test demand. It takes a weekend with no code. Write it so a stranger instantly gets what it does and why they would want it, using how to build a landing page that converts. The button does not lead to a real app yet. It leads to your next test.
What is the difference between a fake door and a concierge MVP?
Both let you test an app without building the app, but they answer different questions.
A fake door test puts a button for your app in front of strangers and counts how many click it. When they click, they hit an honest “we are building this, want early access?” message and you capture their email. The click is a vote for demand. It answers “do people want this enough to reach for it?” Full walkthrough in what a fake door test is and how to run one.
A concierge MVP is where you deliver the app’s result manually, by hand, to a few real users, no software at all. If your app idea is “auto-generate flashcards from a photo of your notes,” you skip the app and just make the flashcards yourself for five classmates who text you photos. It answers “if I actually solve this problem, will people use it and come back?” That is the concierge MVP, explained.
Use the fake door to test whether people want it. Use the concierge MVP to test whether the solution actually helps once they have it. Passing both, with strangers, is stronger evidence than any amount of code.
Set your pass number before you look at the data
Here is the discipline that separates real validation from fooling yourself. Before you run any test, write down the exact result that counts as a yes.
Not “let’s see how it goes.” A number. Something like: “If at least 20 out of 200 strangers who see my landing page give me their email, the idea passes.” You decide this in advance because if you wait until after you see the data, you will always find a way to read a weak result as encouraging. A pass condition set beforehand is the only kind you can trust.
The strongest signal you can get short of real usage is money. If you can get even a handful of people to pre-pay or put down a deposit before the app exists, you have proof most founders never bother to collect. That is the leap from a landing page to pre-selling before you build. A stranger reaching for their card is worth more than a hundred people saying “cool idea.”
And if the numbers come back weak? That is not a failure, that is the whole system working. A fast, cheap no means you get to spend your next month on a better idea instead of coding a dead one. Learning to hear it is a skill in itself, covered in 7 early signs your startup idea won’t work.
When you are finally allowed to write code
You have earned the right to build when you have evidence, not enthusiasm: strangers who have the problem, who took a costly action toward your solution, and who hit or beat the pass number you set in advance. When people you have never met are signing up, replying, or paying, that is your green light.
Even then, do not jump to a full app. Your first version should be the smallest thing that delivers the core result, which for many ideas is not an app at all, it is a website before an app. And you can likely build it with free no-code tools instead of writing code from scratch, which keeps you fast and cheap even after validation.
Running this exact loop, on your own idea, with people who have done it before, is what the first week of the batch0 program is built around. You come in with an app idea and leave the Validate sprint knowing whether real strangers want it, before you have sunk a semester into building it. Applying is free and you only pay tuition if you get in, so you can apply here without risking anything to find out.
For now, you do not need any of that to start. Pick your idea. Find 10 people who have the problem. Set your pass number. Put a fake door in front of strangers this weekend, and let what they do, not what they say, tell you whether to open your code editor at all.