How to Validate Your App Idea Before Building

Spending months building something nobody wants is one of the most painful experiences in tech. The good news: most of that risk is avoidable if you validate before you build.

What validation actually means

Validation isn't market research. It's not asking people "would you use this?" — people are bad at predicting their own behavior. Validation means finding evidence that a specific person will take a specific action (pay, sign up, change a habit) to solve a specific problem.

The three fastest validation methods

1. The fake door test

Build a landing page describing the product. Add a call-to-action — "join the waitlist" or "get early access." Run traffic to it. If conversion rates are meaningful (>5% for a B2B product, >15% for consumer), you have signal.

You're measuring demand, not opinions. The page doesn't need to be beautiful. It needs to be honest about what the product does.

# A fake door can be as simple as:
# 1. A Carrd.co landing page (30 minutes)
# 2. A Google Form for signups
# 3. $100 in targeted social ads

2. Concierge MVP

Do the thing manually before automating it. If you want to build a tool that analyzes competitors' pricing, do it manually for five paying customers first. Charge them. Learn what actually matters before writing a line of code.

Concierge MVPs prove two things at once: that the problem is real and that someone will pay to solve it.

3. Pre-sell before you build

Write a clear description of what you're building. Set a price. Ask people to pay now for delivery later. This is the highest-signal test available — it separates people who say they're interested from people who actually are.

Even five pre-sales at a meaningful price point is enough signal to start building confidently.

What to do with the results

Validation doesn't give you certainty — it gives you better odds. If your fake door gets 0.1% conversion, something is wrong (messaging, audience, or the idea itself). If your concierge MVP has a 0% retention rate, the problem may not be painful enough.

Use negative signals as quickly as positive ones. Failing fast on a bad idea is a win.

The one question that matters

Before building anything, answer this: who specifically will use this, and what will they stop doing instead?

If you can't answer that clearly, no amount of code will save you. Start there.