How to validate an app idea before you build it

The cheapest time to find out an app idea is wrong is before anyone writes code. To validate an app idea, you look for evidence that a specific group of people has the problem, cares enough to change what they do, and would use your solution. Opinions from friends do not count. Behavior does.

Why most attempts to validate an app idea go wrong

Most founders do some validation. The trouble is that it is usually the comfortable kind.

• They ask people if they like the idea. People are polite, so they say yes.
• They count waitlist sign-ups without asking what the sign-ups would actually do.
• They test the part of the idea they are sure about, and skip the part that scares them.

Good validation is uncomfortable on purpose. It goes looking for the reason the idea fails.

Step 1: Write down your riskiest assumption

Every app idea rests on a stack of assumptions. Write them out as plain sentences, then sort them by two questions: how sure are you, and how bad is it if you are wrong?

A typical list for a meal-planning app might look like this:

Assumption	How sure?	Cost if wrong
Busy parents struggle to plan weekly meals	Fairly sure	High
They would plan in an app instead of a notes list	Unsure	High
They would pay $6 a month for it	Unsure	High
They want recipes from a specific diet	Unsure	Medium
Grocery delivery integration matters	Guessing	Low for now

Start with the assumption that is both uncertain and expensive. Here that is the second line. If parents will not switch from their notes app, nothing else matters.

Step 2: Talk to people who have the problem

Interviews are the fastest way to validate an app idea at the problem level. Aim for ten to fifteen conversations with people who match your target user. Friends, investors, and other founders do not count here.

Ask about the past, not the future

“Would you use an app that…” gets you a guess. “Tell me about the last time you…” gets you a fact. Good questions sound like this:

1. When did you last run into this problem?
2. What did you do about it?
3. What did that cost you, in time or money?
4. What have you tried before? Why did you stop?
5. Who else is involved when this happens?

Listen for effort

The strongest signal is that people already spend effort on the problem. A spreadsheet they maintain. A tool they pay for and complain about. A workaround they built themselves. If nobody has tried to solve it, the problem may not hurt enough.

Step 3: Run a cheap test of behavior

Once the problem is confirmed, test whether people will act on your solution. Pick the cheapest test that answers your riskiest question.

• A landing page with a clear offer. Describe the app, show the price, and ask for an email or a deposit. Measure the share of visitors who take the step, not the raw count.
• A clickable prototype. Put a realistic flow in front of five to eight users and watch them try a task. Do not explain. Note where they hesitate.
• A concierge test. Deliver the result by hand for a few users. If you are building a meal planner, send them a plan by email every Sunday. If they stop reading by week three, an app will not save it.
• A pre-sale. Ask for money before the product exists, with a full refund if you do not ship. Payment is the strongest signal you can get.

Step 4: Set a pass or fail line before you start

Decide what result would change your plan before you see the data. Otherwise every result looks like a reason to continue.

Write it as a simple rule: “If at least 8 of 15 interviewees describe a workaround they use today, the problem is real.” Or: “If fewer than 3% of landing page visitors leave an email, we rethink the offer.” The exact numbers depend on your market. The point is to commit to them in advance.

A test you cannot fail is not a test. It is a ritual.

Step 5: Turn what you learned into a first release

When the problem and the solution both hold up, the next step is a small working product. Not the full plan. One user, one core journey, built well enough that the results mean something.

This is where validation hands over to scope. Take the notes from your interviews and tests and use them to decide what goes into the first release and what waits. Our posts on what an MVP is and MVP feature prioritization cover that step in detail.

Batriders offers a product validation sprint as part of our product design work. In our two-week 2Sprint, the first three days are a business and finance plan: we test the idea, size the market, map competitors, and model the numbers before any design starts.

What validation looks like on a calendar

You do not need months. A focused round looks roughly like this:

Week	Focus	Output
1	Assumption list, recruit users, first interviews	Ranked risks, 5 to 8 interviews done
2	Remaining interviews, landing page or prototype	Problem confirmed or rejected
3	Behavior test and pass or fail review	A decision: build, change, or stop

Three weeks of honest testing can save three months of building the wrong thing.

Frequently asked questions

How many people do I need to talk to?

For problem interviews, ten to fifteen is usually enough to see patterns. If the answers are still all over the place after fifteen, your target user is probably defined too loosely.

Can I validate an app idea without building anything?

Yes, at the problem level and often at the solution level. Interviews, landing pages, prototypes, and concierge tests need little or no code. What you cannot fully test without a working product is retention, which is what an MVP is for.

What if people say they love the idea but nobody signs up?

Trust the sign-ups. Kind words cost nothing. Look at your offer, your price, and whether you reached the right people before you change the idea itself.

Should I worry about someone stealing my idea?

Rarely. Ideas are common and execution is hard. The risk of building something nobody wants is much larger than the risk of a stranger copying a conversation.

Validation will not guarantee a hit, but it will tell you early when you are about to build a miss.