How to Validate Your App Idea Before Writing a Single Line of Code
Most apps fail because they solve a problem that doesn't exist. Not because the code was bad. Not because the design was ugly. Because the founder skipped the boring bit and went straight to building.
I've watched it happen more times than I can count. Someone walks in absolutely certain the world needs their app. Six months and $80k later, they've got a polished product sitting in the App Store with 11 downloads. Nine of those are family members.
The product was fine. Nobody asked for it.
We run every idea through five steps before we write a line of code. Some founders hate it. Most thank us later. Here's the framework.
Why most people skip validation
Because it's boring. Mocking up screens and choosing colour palettes feels like progress. Calling strangers and asking awkward questions about their problems feels like homework.
So founders skip it. They tell themselves they already know the market. They've "done the research," which usually means they Googled it and asked three mates who said "yeah that sounds cool."
That's confirmation bias with extra steps.
The best founders we work with are the ones who actively try to kill their own idea before building it. If the idea survives that, it's probably worth building.
The cost of skipping this isn't just money. It's a year of your life. It's the gut punch of launching something you poured everything into and hearing... nothing. Spend four weeks testing your idea now, or spend four months building the wrong thing. Your call.
Step 1: Talk to 20 real people (not your mum)
Your mum thinks your app idea is brilliant. So does your best mate. They love you. That doesn't mean they understand your market.
Talk to 20 people who actually have the problem you're trying to solve. Not 5. Not 10. Twenty. The first few conversations you'll hear what you want to hear. By conversation 12, real patterns start showing up. By 20, you'll know whether this thing has legs.
Questions that actually work:
- "Tell me about the last time you dealt with [problem]. What happened?"
- "What do you do about it right now? Walk me through it."
- "What's the most annoying part of how you currently handle this?"
- "If something fixed this completely, what would it look like?"
- "How much time or money does this problem cost you?"
Don't ask "Would you use an app that does X?" That question is useless. People say yes to be polite. You're looking for existing pain, not hypothetical interest.
If 20 people can't describe the problem with any emotion or specificity, you don't have a problem worth solving. Walk away. You just saved yourself a fortune.
Step 2: Find the existing ugly solution
This sounds backwards, but you want to find competitors. You want messy, duct-taped-together workarounds that people are already using.
Why? Because if people are already spending time and money on a bad solution, the problem is real. They're not waiting for your app to start caring about this. They already care.
Things to look for:
- Spreadsheets doing jobs spreadsheets were never designed to do
- WhatsApp groups somehow holding together entire business workflows
- People paying for software that does 10% of what they need
- Manual processes that make you wince. Pen and paper, phone calls, sticky notes
The uglier the workaround, the bigger your opening. If people are suffering through something terrible, they'll pay for something better.
But if nobody has even bothered to hack together a solution? Be careful. That usually means the problem isn't painful enough for anyone to act on.
Step 3: Pre-sell it before you build it
This is where founders get uncomfortable. Good.
Before you build anything, try to get actual money from people. Not "I'd definitely buy that." Actual dollars. A deposit. A pre-order. Something that costs them more than a polite nod.
How to do it:
- Write a one-pager describing what the app does, who it's for, and what it costs. No mockups. Just clear language.
- Set up a Stripe payment link with a "founding member" price. Early access, discounted rate.
- Go back to those 20 people from Step 1. Show them the one-pager. Ask them to put money down.
If 5 out of 20 people pay a deposit, you've got signal. If nobody will pay $50 for early access to the thing they said they desperately need? You've got a demand problem, and it's better to know that now than after you've spent $100k.
Hypothetical interest is free. Commitment costs something. That's what makes it useful.
Step 4: Build a landing page and drive traffic
You've validated with people you know. Now test with strangers.
Throw up a simple landing page. Not your final website. A single page with:
- A headline that names the problem
- A subheadline with your solution
- A few bullet points on what it does
- A signup button: "Join the waitlist" or "Get early access"
Spend $300-500 on targeted ads. Instagram, Facebook, Google, wherever your people are. You're answering one question: will strangers care enough to give you their email?
Watch three numbers:
- Cost per click. Are people interested enough to tap?
- Conversion rate. Of those who land on the page, how many sign up? Above 10% is strong. Below 3% means your messaging or your market is off.
- Email engagement. Do signups open your follow-up emails? Do they reply?
A $500 ad test beats a $100,000 build that nobody wants. Every time.
Step 5: Set your kill criteria before you start
Before you start validating, decide what would make you walk away. Write it down. Be specific.
- "If fewer than 4 out of 20 people describe this as a top-3 pain point, I'll pivot."
- "If I can't get 3 pre-sale commitments in 2 weeks, I'll rethink the positioning."
- "If my landing page converts below 5% after $500 in ad spend, I'll try a different angle before building."
Why set these upfront? Because in the middle of validation, your brain starts negotiating. "Well the numbers aren't great, but..." "Maybe I just need to explain it better..." "The sample size is too small..."
Sunk cost fallacy will destroy you if you let it. The kill criteria are there to protect you from yourself. They force honesty when your ego is screaming at you to keep going.
The founders who do best aren't the ones who never get it wrong. They're the ones who figure out they're wrong quickly and move on to something better.
So what?
Building an app is not the hard part. Picking the right app to build is.
This process won't crush your idea. It'll either confirm it or save you from wasting a year on something that was never going to work. Both of those are good outcomes.
The founders who come through this with strong signal build with real confidence. They launch knowing people actually want what they've made. And the ones whose idea doesn't survive? They save six figures and redirect that energy into something better.
Best money you never spent.
