How to Validate Your App Idea Before Writing a Single Line of Code

You have the idea. You’re excited. You can already see the product in your head and you want to start building. Stop. Not because the idea is bad — it might be great — but because you’re about to spend three to six months building something based entirely on your own assumptions. Here’s a framework that gets you real data in 48 hours, from real people, before you write a single line of code.

The Problem With “Doing Research” Before Building

Most indie hackers either skip validation entirely or do it in a way that produces no useful information. “Doing research” usually means reading Reddit threads, watching YouTube videos about your target market, and selectively absorbing content that confirms what you already believe.

That’s not research. That’s procrastination with a productivity costume on.

The other version is the survey trap. You post a Google Form in three communities, get 40 responses, and 35 people say “yes, I’d use something like that.” That number is almost meaningless. People say yes to hypothetical products constantly. They pay for real ones at a 10-20x lower rate. A 35/40 survey result has convinced hundreds of founders to spend months building things nobody bought.

Real validation answers one specific question: will a specific person, in a specific situation, do something concrete that indicates they actually want this? “Something concrete” means one of three things — they pay money, they give you their email address with clear intent to use the product, or they describe the problem to you unprompted in specific enough detail that you couldn’t have invented it.

Everything else is a weak signal. Useful context, but not evidence. Don’t make major building decisions based on weak signals.

The 3-Question Validation Test

Before building anything, you need clear answers to these three questions. Not assumptions — actual evidence gathered from real conversations or observable behavior.

Question 1: Do people actively experience the problem your product solves?

Not “would they have this problem.” Do they currently experience it, regularly, in a way they notice and care about? The test: can you find five people online — in forums, subreddits, Slack groups — who have described this problem in their own words without being prompted? Spend 30 minutes searching. If you can’t find it, the problem may not be felt acutely enough to drive purchasing decisions.

Question 2: How are they solving it right now?

If the answer is “they’re not solving it” or “nothing exists” — be skeptical. Usually this means either the problem isn’t painful enough to warrant action, or you’re wrong about the market. The sweet spot: people are solving it with something clunky, expensive, or time-consuming. That gap is where products live. If they already have a decent solution they’re happy with, your path to switching them is long and expensive.

Question 3: Would they switch to something better?

People are surprisingly reluctant to change tools they’re already using, even bad ones. Switching costs are real: learning curve, data migration, habit change, organizational buy-in. Your product needs to be meaningfully better — not slightly better — to overcome that inertia. Ask directly: “If a tool that did X existed, would you stop using your current solution?” Watch how long they take to answer. Immediate enthusiasm means something. A long pause followed by “probably, yeah” means a lot less.

Running a Fake Door Test in 48 Hours

A fake door test is a landing page describing a product that doesn’t exist yet, with a signup or waitlist form. You drive traffic to it, measure the signup rate, and use that as a proxy for real demand. Done right, you get actual data in 48 hours without writing a line of code.

Here’s exactly how to run one:

Day one, 3-4 hours: Build a one-page landing page. Use Carrd ($9/month), a Webflow free tier, or even a Notion page. Write one headline describing the outcome your product delivers. Write three bullet points describing core benefits, not features. Add an email capture form with a clear CTA — “Get early access” or “Join the waitlist.” That’s it. No pricing, no screenshots, no polished design. Get it live.

Day one, 1-2 hours: Write a post for the community where your target user spends time. Don’t pitch the product — describe the problem. “Anyone else frustrated by X? I’m exploring building something that does Y. Would that be useful? Drop your email here if you want early access.” Post it in two to three relevant communities — the specific subreddit, Slack group, or forum where your actual target user is.

Day two: Check your signup numbers. A 5% conversion rate from post views to email signups is decent. 10% or above is strong. Under 2% is a signal to reassess the positioning or the problem itself. If you get zero signups from a post that got 100 views, something fundamental isn’t landing.

This isn’t scientifically rigorous, but it’s real-world data from people who took a concrete action. That matters far more than survey responses.

The Struggling Entrepreneur newsletter covers validation frameworks and post-mortem case studies from indie hackers who ran tests like this — including the ones that produced surprising results.

Talking to 10 Real People (Without Hating It)

The fake door test tells you whether people are interested. Real conversations tell you whether you understand the problem well enough to build the right solution.

You need five to ten conversations. Not fifty. Not five hundred. Five specific people who currently experience the problem and use some alternative solution.

Find them where they already are. The subreddit for your target industry. A niche Facebook group. A Slack community for your target profession. Don’t post “looking for people to interview” — that phrasing signals research project, not genuine interest. Instead, engage authentically — answer questions, contribute value — then DM individuals whose posts demonstrate they have the exact problem you’re solving.

Your outreach message: “Hey, I saw your post about [problem]. I’m working on something related and would love to hear how you currently deal with it. Fifteen minutes, no pitch, I promise. Would you be open to a quick chat?”

In the conversation, follow three rules strictly. First: don’t describe your product. Second: don’t pitch anything. Third: ask about the past, not the future. “Tell me about the last time this happened” produces real data. “Would you use a product that…” produces polite speculation. Past behavior is evidence. Future behavior is a guess.

After five conversations, you’ll know more than any amount of desktop research could tell you. You’ll know the exact language people use to describe the problem, which alternatives they’ve tried and rejected, what made those alternatives fail them, and what a solution would actually need to do to get them to open their wallet.

After validation, if you still believe in the idea, build. See building an MVP without a team for how to scope the build so you don’t over-engineer before you have users. And if your validation conversations sent you to a slightly different problem than you started with — build for that one instead. That’s the whole point of doing this first. Also check customer discovery for indie hackers to go deeper on the conversation side of this process.

Don’t let “validation” become another form of avoidance. A fake door test and five conversations is enough. After that, the next thing you learn will come from building and shipping, not from more research.