How to Validate an App Idea Before You Build It (7 Steps)

To validate an app idea, find out whether real people already have the problem, and whether any of them will give you something (an email, time, money) for a fix. Do that before you open Cursor or Claude Code. You can do it in about two weeks with a few conversations and a one-page smoke test.

AI tools made building cheap. They didn't make wanting cheaper. You can ship a working app in a weekend and still have nobody who cares.

Why bother, if building is fast now?

Because the usual way these things die is not bad code. In CB Insights' older review of 101 startup post-mortems, "no market need" was the most-cited reason at 42%. A newer CB Insights pass on VC-backed shutdowns put poor product-market fit at 43%. Both are summarized here. The samples are startups, not weekend projects, so don't treat the numbers as a forecast for your side project. The pattern still holds: a finished product tells you nothing about whether anyone wants it.

Your time is the cost. A weekend of prompting is a weekend you don't get back, and a dead app is hard to abandon once it looks finished.

Step 1: Write the problem in one sentence

Write the problem, not the app. "Freelance designers lose track of which clients owe them money" is a problem. "An AI-powered invoicing dashboard" is a solution in search of one.

Use this template: [Specific person] struggles with [specific situation] because [reason], and today they deal with it by [current workaround].

If you can't fill in the workaround, you probably don't know the problem well enough yet. If there's no workaround at all, be suspicious. Usually that means people don't care enough to bother.

Step 2: Talk to 8–10 people who have the problem

Don't ask friends. Find people in the group you described: a subreddit, a Slack community, a LinkedIn search, a coworker's coworker. Ask for 15 minutes.

The trick is not to pitch. The Mom Test, from Rob Fitzpatrick, boils down to three rules: ask about their life, ask about specific things that already happened, and let them do most of the talking. "Would you use this?" gets you a polite yes. "When did this last happen?" gets you a story.

Questions worth asking:

• When was the last time you ran into this? Walk me through it.
• What did you do about it?
• What have you tried, and what did you pay for?
• What's the most annoying part?
• Who else deals with this that I should talk to?

Take notes on what they did, not what they said they'd do. Someone who built a spreadsheet to cope, or paid for a clunky tool, has a real problem. Someone who says "yeah, that sounds useful" has given you a compliment, which costs them nothing.

Step 3: Look at what already exists

Spend an hour on this. Search the app stores, Product Hunt, Reddit and "[problem] alternative" queries. Write down the five closest competitors and what people complain about in their reviews.

Competitors are usually good news. They show that someone pays to solve the problem. What you need is a reason a specific group would switch: cheaper, simpler, built for one niche, or fixing the complaint that keeps showing up in one-star reviews. "Like X but with AI" is not a reason.

Step 4: Build a smoke test, not the app

A smoke test is a landing page for a product that doesn't exist yet. Its job is to see whether strangers respond to the promise. One validation guide lays out a sequence of problem interviews, then a landing page test, then a pre-sale, then a hand-delivered version.

This is where your AI tools are useful. Making a one-page site takes minutes in Lovable, Bolt, v0 or whatever you already use. Here's a prompt to start from:

Build a single-page landing page for a product that doesn't exist yet.

Audience: [WHO]
Problem: [ONE SENTENCE]
Promise: [THE OUTCOME THEY GET, in plain words]

Sections: headline, a 3-line explanation, one placeholder for a
mockup image, and an email form with a "Join the early-access list"
button.

Rules: honest copy only. No fake testimonials, no made-up user
counts. After signup, show a thank-you message and ask one question:
"What's the main thing you'd want this to do?"
Track page views and form submissions so I can compute the
conversion rate.

Then send real traffic to it. Post in the communities where you did your interviews, message the people you talked to, or put a small amount behind an ad. Friends and family clicking through doesn't count. The point of a smoke test is to see whether strangers bite, not whether supportive people do.

Step 5: Ask for something that costs them

An email is a weak signal. It costs the visitor three seconds. Move up the ladder when you can.

Time, reputation and money are the things to count. If nobody will give you any of them, that's your answer, even if the signup count looks fine.

Step 6: Set your go/stop numbers before you look

Decide the thresholds first, while you're still neutral. Otherwise you'll read any result as a yes. Guides recommend setting go, pivot and stop thresholds up front so the data outweighs your attachment to the idea.

Conversion benchmarks differ a lot between sources, and they depend on your traffic, so I won't hand you one number. Pick yours and write it down. A reasonable shape:

• Go: at least 5 of your interviewees describe the same problem, and several people from cold traffic sign up or agree to a call.
• Pivot: people confirm the problem but ignore your solution. Change the solution or the audience and test again.
• Stop: few people have the problem, or nobody takes any action beyond a compliment.

Those counts are a starting suggestion, not a rule. Choose what would convince you, and stick to it.

Step 7: Deliver it by hand, then build the smallest version

If the signals are good, don't build the whole thing yet. Do the job manually for your first few people. This is called a concierge MVP. If your app would send a weekly report, send that report yourself from a spreadsheet. You'll learn what people want and what they ignore, and the output tells you exactly what to prompt.

When you do open your AI editor, you'll have something most vibe coders don't: a one-sentence problem, a real user, and a short list of the one thing they asked for. Put that in your project's rules or spec file. It makes the prompts better and keeps you from adding features nobody mentioned.

Common ways people fool themselves

• Counting friends as data. They like you. That's all.
• Pitching in interviews. Once you describe the app, the answers become feedback on your pitch.
• Treating a clean demo as proof. AI-built prototypes look good fast. Looking good isn't demand.
• Moving the goalposts. If you missed your number, don't invent a new one.

FAQ

How long does it take to validate an app idea?

Roughly two weeks if you go steadily: a few days of interviews, a day to make the page, and a week or so of traffic. One guide I found lays it out as a four-week plan, which is also reasonable if you're doing this around a job. The timeline matters less than collecting actual behavior rather than opinions.

Do I need to spend money on ads?

No. You can reach people for free through communities and direct messages, and often that finds better-targeted people than ads do. If you do use ads, sources I read suggest small budgets, though the amounts vary widely. Start low, and only increase spend once the page gets a clear response.

What if I've already built the app?

Run the same process on it. Put up a simple page, talk to people who have the problem, and see if anyone will pay or commit. It's less fun to learn this after building, but it's far better than learning it after months of marketing something nobody wants.

Cover photo: Amélie Mourichon on Unsplash