How to Validate an App Idea Before You Build It
Ways to validate an app idea before you build: problem interviews, smoke tests, waitlists, pre-sales and concierge tests, and what each one really proves.
Mythex Team · · 6 min read
To validate an app idea, find out whether a specific group of people has the problem, is already trying to solve it, and would give up something real — time, an email, money — for your solution. Start with conversations, move to a landing page or waitlist, and treat a pre-sale or a returning user as the strongest proof. Each step costs a little more and tells you a little more.
Validation doesn't prove an idea will succeed. It lowers the odds of spending months on something nobody wants.
What you are actually testing
"Is this a good idea?" is too vague to test. Break it into questions you can answer:
| Question | What a "yes" looks like |
|---|---|
| Does the problem exist? | People describe it without prompting, in their own words |
| Is it painful enough? | They've tried workarounds, spreadsheets or other tools |
| Who has it most? | One group keeps coming up — a role, industry or situation |
| Will they pay? | They already spend money or time on it, or they pre-order |
| Can you reach them? | You know where they gather: a forum, a trade group, a newsletter |
The last one is often skipped. A real problem you can't reach customers for is still a hard business.
Step 1: Write down your riskiest assumption
Before any research, write the idea as one sentence: "[Who] struggles with [problem] and would use [solution] because [reason]." Then list what must be true for it to work, and circle the item you are least sure of. That is what you test first.
For a scheduling app for dog groomers, the riskiest assumption might not be "groomers need scheduling" — they obviously do — but "groomers are unhappy enough with their current tool to switch".
Step 2: Problem interviews
Interviews are the cheapest, highest-signal method, and the easiest to do badly. The goal is to learn about the person's current behaviour, not to pitch.
Who to talk to
People who match your one-sentence description. Friends and family are fine for practice but will be kind rather than honest. Find real prospects in the places they already are: industry groups, subreddits, local business associations, your own network on LinkedIn.
What to ask
Ask about the past, not hypothetical futures:
- "Tell me about the last time you dealt with [problem]."
- "What did you do about it? What tools did you use?"
- "What was annoying about that?"
- "Have you paid for anything to fix it? Why or why not?"
- "Who else is involved when this happens?"
What to avoid
- "Would you use an app that…?" Almost everyone says yes to be polite.
- Showing your solution too early. Once they see it, they react to it instead of telling you about their problem.
- Counting compliments. "That's a great idea" is not evidence. "Can I try it when it's ready?" is a little. "Here's my card" is a lot.
Take notes, and afterwards write the three things you learned. When several people describe the same pain in similar words, write those words down — they become your landing page headline.
Step 3: Check what already exists
Search for the problem, not your solution. Look at existing products, their pricing pages and their public reviews. Competition is usually a good sign: it means people pay to solve the problem. What you're looking for is a gap — a group the existing tools serve badly, a price point nobody covers, or a workflow that is still done in spreadsheets.
If nothing exists at all, find out why. Sometimes it's an opportunity; often it means the problem isn't painful enough to pay for.
Step 4: Smoke test with a landing page
A smoke test is a page that describes the product as if it exists, with a clear action: join the waitlist, request access, or pre-order. You then send targeted people to it and measure how many take the action.
What the page needs:
- A headline that names the problem in your interviewees' words.
- Three or four specific benefits — what changes for the user.
- One call to action.
- An honest note that the product is in development, so nobody feels tricked.
Then drive traffic from the places your audience is. A small paid ad test aimed at a narrow audience can work; so can posting in communities, as long as you follow their rules. How to build a landing page that converts covers structure and copy.
Reading the results
There's no universal "good" conversion rate, so compare against yourself: run two headlines or two audiences and see which does better. The most useful output isn't the percentage; it's the list of people who signed up. Email them and ask for a call.
Step 5: Build a waitlist — and use it
A waitlist collects emails from interested people before launch. It's useful for two reasons: it gives you people to interview, and it gives you an audience on launch day.
Its weakness is that signing up is nearly free. Make the list do more work:
- Ask one question on sign-up, like "What do you use for this today?"
- Reply personally to early sign-ups and ask for 15 minutes.
- Send a short update every few weeks so the list doesn't go cold.
How to build a waitlist page covers the build, including where the emails are stored.
Step 6: Pre-sell or take a deposit
The strongest early signal is money. Offer early access at a discount, a founding-member price, or a refundable deposit, and see who pays. Use a payment link from your payment provider; you don't need a finished product.
Be straightforward: say when you expect to deliver, and refund anyone who asks. A pre-sale that nobody takes is also a result — it may mean the price is wrong, the audience is wrong, or the pain is not as sharp as it sounded in interviews.
Step 7: Concierge and Wizard-of-Oz tests
Sometimes the fastest "product" is you.
- Concierge test: deliver the outcome by hand. If the app would generate weekly reports, make them yourself in a spreadsheet and email them. You learn exactly what users value before automating it.
- Wizard-of-Oz test: users see a simple interface, but behind it you do the work manually. The user experiences the product; you learn whether they come back.
Both are slow to scale, which is the point. You only automate what has proved worth doing.
Step 8: Build a small MVP and watch behaviour
A minimum viable product is the smallest version that does the one core job. With AI app builders, a working MVP with a database and login can take days rather than months, so it's now reasonable to make it part of validation — see what an MVP is.
The key metric is not sign-ups but return use. Do people come back a second and third time without you nudging them? Do they invite a colleague? Do they complain when it breaks? Those are signs the app matters to them.
Comparing validation methods
| Method | Cost | Time | What it proves | Where it misleads |
|---|---|---|---|---|
| Problem interviews | Free | Days | The problem is real and how people describe it | Politeness; talking to the wrong people |
| Competitor research | Free | Hours | People already pay to solve it | Assuming a gap exists without checking why |
| Landing page smoke test | Low | Days | The message attracts clicks | Clicks aren't commitment |
| Waitlist | Low | Weeks | Ongoing interest; a launch audience | Emails are cheap to give |
| Pre-sale / deposit | Low | Days to weeks | Willingness to pay | Early adopters may differ from the mainstream |
| Concierge test | Your time | Weeks | The outcome is valued | Hard to separate you from the product |
| MVP | Low to medium | Days to weeks | Real usage and retention | Low usage may be a product issue, not the idea |
When to stop, change or continue
Set your threshold before you start — for example, "ten interviews, three people say they'd pay, one pre-sale". Then be honest:
- Continue if people keep describing the same pain and some commit money or time.
- Change if the pain is real but for a different group, or at a different price, than you assumed. That's common and useful.
- Stop if nobody has tried to solve the problem, nobody will pay, and you can't reach the people who have it.
Stopping early is a good outcome. It frees you to test the next idea.
Validating with Mythex
Mythex fits the later steps of this process. You can describe a landing page with a waitlist form and have it live on a public URL the same day, with sign-ups saved to a database, then turn the same project into a small MVP when the signals are good. It's free to start, and the waitlist walkthrough in the docs shows the steps. If you're weighing budget, how much it costs to build an app compares the options.
Questions
What is the fastest way to validate an app idea?
Talk to five to ten people who have the problem, asking about what they do today rather than pitching your idea. If they describe the problem clearly, have tried to solve it and are spending time or money on it, you have a signal worth testing further with a landing page or pre-sale.
Is a waitlist enough to validate an idea?
Not on its own. Signing up with an email costs people almost nothing, so a waitlist shows interest, not willingness to pay. Treat it as a list of people to interview and sell to, and look for stronger signals like pre-orders or deposits.
How many customer interviews do I need?
There is no magic number. Keep going until the answers stop surprising you — for a narrow audience that can happen after a handful of conversations. If every interview tells a different story, your audience is probably too broad.
Should I build an MVP to validate, or validate before building?
Do the cheap checks first: interviews and a landing page cost days, not weeks. With AI app builders a small MVP is now cheap too, so building one can be part of validation — as long as you put it in front of real users quickly and measure whether they come back.