How to Validate an App Idea Before You Spend Money

You have an app idea that keeps you up at night. Friends say it's great. You can picture the screens. Before you spend $25,000 to $50,000 building it, you want to know whether strangers will pay for it. To validate an app idea, you collect evidence, in rising order of strength, that a specific group of people has the problem, cares enough to act, and will pay your price. Compliments don't count. Money, time and commitments do. This guide gives you a step-by-step validation ladder, the interview questions that get honest answers, a scorecard to judge your evidence, and the rules for when to stop.

Why validation comes first

When CB Insights examined 431 venture-backed companies that shut down since 2023, 70% had run out of capital. But the analysis points to deeper causes: poor product-market fit in 43% of cases, bad timing in 29% and unsustainable unit economics in 19%. Running out of money is usually where the story ends, not where it starts.

The same pattern shows up in older research on software projects. In the Standish Group's original CHAOS report, IT executives ranked "lack of user input" as the top factor behind troubled projects, cited in 12.8% of responses, just ahead of incomplete requirements. Building without talking to users is an old mistake, and still a common one.

Validation is cheap insurance against both.

The validation ladder

Each rung gives stronger evidence than the one below it. You don't need every rung, but you should climb as high as your budget and risk require.

Rung 1: problem interviews that don't lie

People want to be nice. If you describe your idea and ask whether they like it, most will say yes. That's why good interviews avoid pitching altogether.

Questions to ask

• "Tell me about the last time you dealt with [the problem]."
• "What did you do about it?"
• "What did that cost you, in time or money?"
• "What have you tried to fix it? What did you pay for that?"
• "What's the hardest part of [the task] today?"
• "Who else deals with this? Can you introduce me?"

Questions to avoid

• "Would you use an app that does X?"
• "How much would you pay for this?" (asked cold, before any context)
• "Do you think this is a good idea?"

The book The Mom Test by Rob Fitzpatrick covers this style in depth and is worth an evening.

What a strong signal sounds like

• They describe the problem before you do.
• They've already tried to solve it, with a spreadsheet, a hire or another tool.
• They've spent money on it.
• They ask when they can have your solution, or offer to introduce you to others.

Aim for at least 10 conversations with people who match your target customer exactly. Paul Graham's essay Do Things that Don't Scale puts the mindset simply: "You can't wait for users to come to you. You have to go out and get them." That applies to validation too.

Where to find people to interview

Finding the right people is often harder than asking the right questions. Places to start:

• Your own network, one step removed. Ask friends to introduce you to someone who has the problem, rather than interviewing the friends themselves.
• Where your customers already gather. Trade associations, local business groups, industry forums, subreddits and professional Slack or Facebook groups. Read the rules and contribute before you ask.
• Their suppliers and advisers. Accountants, consultants and equipment vendors talk to your target customers every day and can introduce you.
• Cold outreach with a specific ask. A short, personal message asking for 15 minutes to learn about how they handle one task gets more replies than a survey link.

Keep notes in the same format for every conversation: who they are, the last time the problem happened, what it cost, and what they tried. Patterns are much easier to spot when the notes line up.

Rung 2: the landing page test

Write a one-page description of the product: who it's for, the problem, the outcome, and a price. Add one call to action, either "Join the waitlist" or, better, "Buy now" leading to a page that explains it's coming soon.

Then send targeted people to it: from your interviews, from communities where your customers gather, or from a small ad budget. Measure:

• Visitors who reached the page.
• Actions: email sign-ups, or clicks on a priced "buy" button.
• Replies: people who respond when you email them personally.

A priced button tells you far more than a free waitlist. People sign up for anything free.

Rung 3: deliver it by hand

Before you build software, deliver the outcome manually. If your app will send invoice reminders, send them yourself for five clients. If it will match tutors to students, match them yourself over email.

This is sometimes called a concierge test. It shows whether people come back, what they actually need, and which features matter. It also gives you your first customers, who may become your first paying users.

Rung 4: ask for money

The strongest evidence before building is a payment. Options, from lightest to strongest:

• A refundable deposit to reserve a spot.
• A discounted annual pre-order for early customers.
• A signed letter of intent with a price, for business buyers.
• A paid pilot with a start date.

If people won't pay a deposit for something that solves a painful problem, that tells you something important about the problem or the price. Our guide to pricing your app helps you set a price worth testing.

Rung 5: a small paid pilot

Once you have commitments, build the smallest version that delivers the core outcome. Ship to your pilot group. Watch whether they use it every week and whether they pay again at renewal.

Usability testing can be small, too. Jakob Nielsen of the Nielsen Norman Group argued that testing with five users finds about 85% of usability problems in a design, and that you learn more from several small rounds than from one big one. Five pilot users watching you is plenty to start.

Worked example: an evidence scorecard

Score your evidence honestly. Here's a scorecard for a hypothetical appointment reminder app for small salons.

Illustration, not a prediction: the weights and results are examples to show the method. Choose your own thresholds before you start.

Before starting, this founder wrote down: "Build if the score reaches 40 and at least 3 salons pay a deposit. Stop if the score is under 20 after 30 days." They hit both build conditions. Without the rule written in advance, it's too easy to call any result a success.

When the answer is "don't build"

Validation is only useful if you're willing to hear no. Signs to stop, pause or change direction:

• You can't find 10 people who have the problem.
• People describe the problem as mildly annoying, not costly.
• Nobody has tried to solve it or spent money on it.
• People love the landing page but won't pay a deposit.
• Your manual version gets used once and forgotten.

A "no" is a result, not a failure. You've saved the cost of building the wrong product. Often the interviews point to a different, better problem nearby. Follow it.

Common validation mistakes

• Only asking friends and family. They're kind, not representative.
• Pitching instead of listening. You learn nothing while you talk.
• Counting likes, follows and sign-ups as demand. They're curiosity.
• Changing the pass mark after the results. Decide it first.
• Validating the problem but not the price. A real problem at the wrong price is still a failed product.

From validated idea to first version

Once your evidence clears the bar, keep the first build small. Cut to the features that deliver the outcome your pilot customers paid for. Our guide to MVP scope explains how, and web, iOS or Android first helps you choose one platform to start. Plan the launch with the app launch checklist, and line up the next wave of buyers with your first 100 customers.

How Ottomind can help

When your idea has cleared validation, Ottomind Studio can build the first version at a fixed price agreed after a scoping call, with UX/UI design included; focused MVPs start from $25,000, with v1 targeted in production within about four weeks of scope sign-off. You own your GitHub, cloud, domain and app-store accounts from day one.

If you're still deciding, start an intake. It gives an AI-assisted stack recommendation and estimate in minutes, so you know what a real build would cost before you commit. That number belongs in your pass-or-fail rule: if your validated demand can't support it, it's better to learn that now.