How to Validate an App Idea (Before Building)

AI tools have made building an app fast. They haven't made it any easier to know whether anyone wants it. That part — validation — is still on you, and it's the cheapest step to do well.

Validating an idea means collecting evidence that real people have the problem, care enough to act, and would use (or pay for) your solution. Here's how to do it in days, not months.

Step 1: Write the idea as a problem, not a product

"An app that uses AI to plan meals" is a product. "Busy parents waste money because they don't plan meals" is a problem. Validation tests the problem first. If the problem isn't real, the product doesn't matter.

Write one sentence: who has what problem, and what they do about it today.

Step 2: Talk to people (the right way)

Find 5–10 people who match the "who." Ask about their past behaviour, not your idea:

"Tell me about the last time you dealt with this."
"What did you try? What did it cost you?"
"What's annoying about how you do it now?"

Avoid "Would you use an app that…?" — people are polite and will say yes. What they did is evidence; what they say they'd do mostly isn't.

Good sign: they describe the problem vividly, have tried workarounds, or have spent money on it. Bad sign: they shrug, or only get interested when you describe your solution.

Step 3: Put up a landing page

A single page that describes the outcome, with one call to action: "Join the waitlist" or "Get early access." Share it where your audience hangs out. (How to build a landing page)

Measure the conversion rate: what share of visitors leave an email. There's no universal benchmark, but a page that gets a few hundred targeted visitors and almost no sign-ups is telling you something.

Step 4: Ask for money (or something that costs them)

The strongest signal is someone paying before the product exists. Options:

Pre-sales: "Founding member, 50% off for life, launches in 6 weeks." A Stripe payment link takes five minutes.
Deposits: a small refundable amount.
Time: a 30-minute onboarding call booked in their calendar.

Ten people paying is worth more than a thousand "sounds cool"s.

Step 5: Do it by hand first

A concierge MVP: deliver the outcome manually. Planning meals? Send three families a plan by email each week. You'll learn what they actually need, which features matter, and whether they keep coming back — before writing a line of code. (What is an MVP?)

Reading the signals

Signal	What it means
People describe the problem without prompting	Real problem
They've already paid for a workaround	Real problem with budget
Waitlist sign-ups from strangers	Interest
Pre-payments	Strong demand
They keep using your manual version	You're onto something
Only friends and family respond	Not validated yet

When to stop

Decide your threshold in advance: "If fewer than 20 people join the waitlist from 500 targeted visitors, I'll rethink the angle." Without a threshold, every result looks encouraging.

Stopping isn't failure. It's the cheapest possible way to find the idea that does work.

The summary

Validate the problem before the product.
Ask about past behaviour, not hypothetical interest.
A landing page and a payment link are the fastest tests.
Doing it by hand teaches you what to build.
Set a success threshold before you look at the results.

When the evidence says build, EasySpawn gets the app online quickly — app, database, your own domain and SSL on one server — so you can keep learning from real users. See how it works for AI-built apps or join the waitlist.

How to Validate Your App Idea Before You Build It