How to validate an app idea before you pay to build it

A founder has spent a year and much of her savings on an app her friends praised and her family thought was brilliant. It went live in the App Store and 40 people downloaded it in the first month. None of them came back. The problem was never the code. Nobody had asked the target group how they solved the problem today, and whether it bothered them enough to switch. That conversation could have cost an afternoon and a cup of coffee.

Validation is the cheapest part of an app project and the one most often skipped. In this guide you get seven concrete tests from the free to the slightly more expensive, a table of what they cost and prove, a decision table for reading the results, and a worked example. It applies to new business ideas and to internal apps, where the target group is your own staff.

What does it mean to validate an app idea?

An idea is validated when you have evidence in place of opinions. Evidence is things people have done: spent time explaining the problem, left their email, clicked an ad, completed a task in a prototype or paid. Opinions are everything people say about the future, such as “I would definitely use that”. Validation has to answer four questions:

1. The problem: Does a specific group have a problem that costs them time, money or nerves today?
2. The behaviour: Do they already do something to solve it, for example with spreadsheets, paper or another product?
3. The solution: Do they understand and use your solution when they try it?
4. Willingness to pay: Will they pay, or will their employer, and how much?

The order matters. Testing a prototype on people who do not have the problem wastes money, and talking price is premature before you know the solution makes sense. Start at the top, and move on only once you have a clear yes on the step before.

Which tests can you run before building the app?

Desk research: what already exists?

Search for the problem the way your customers would phrase it, and see what comes up. Read competitors’ reviews in the App Store and Google Play, especially the two and three star ones. They are the most precise descriptions of what customers miss. Also check whether there are Facebook groups or forums where people discuss the problem. If nobody talks about it anywhere, that is a signal in itself.

Problem interviews: ask about the past

The most important rule in an interview is to ask about things people have done, and to hold back your idea until the end. People are polite, and a question like “would you use an app for this?” almost always gets a yes that means nothing. Ask about the last time the problem occurred. Here are questions you can copy straight into your interview guide. We go deeper in our guide to user interviews.

• Tell me about the last time you faced this problem. What happened?
• How did you solve it? Which tools, papers or people did you use?
• What was the most annoying part of that solution?
• How much time or money does it cost you a month?
• Have you tried to find a better solution? What did you find, and why are you not using it?
• Who else is involved when the problem has to be solved?
• If you could wave a magic wand, what would be different?
• May I show you something in a couple of weeks and hear what you think?

Landing page and ad test: do people act on the message?

A landing page describes the app as if it existed, with a clear button such as “Join early access” or “Reserve your spot”. Send traffic to it with a small ad campaign aimed precisely at the group you interviewed. Measure how many click the ad and how many of those leave their email. Decide your success threshold before the test starts, so you do not explain away a weak result afterwards. Our guide to landing pages shows how to structure the page.

Clickable prototype: can people use the solution?

A clickable prototype looks and feels like an app on the phone, but there is no code behind it. Give five users a concrete task, for example “book a slot for next Tuesday”, and watch them try without helping. It quickly reveals whether the flow makes sense and whether the features you thought were important get used at all. We build clickable prototypes for exactly that purpose, and they can then be used directly as the basis for development.

Concierge test and pre-sales: the strongest evidence

In a concierge test you deliver what the app is meant to do yourselves, with phone, email and a spreadsheet. If the app is meant to match dog owners with dog walkers, you do it by hand for the first 20 customers. It shows whether customers come back, and you learn exactly which steps need automating. Pre-sales go one step further: you ask for payment, a deposit or a signed letter of intent before the app is built. No signal is stronger than money.

How does validation work step by step?

How do you know if the idea is validated?

Worked example: four weeks of validation for under DKK 10,000

Picture an idea for an app that matches busy dog owners with local dog walkers. The figures below are an example, but the sequence is typical. In week 1 the founder interviews 12 dog owners. Nine describe the problem of getting home for the midday walk unprompted, and seven already pay a neighbour or an acquaintance. In week 2 a landing page goes up, and DKK 3,000 in ads brings roughly 1,000 visits and 70 sign-ups. In week 3, five of those who signed up test a clickable prototype and all complete a booking. In week 4 the 70 sign-ups are offered three walks at an introductory price, and 11 pay.

In total, validation cost a month of work and under DKK 10,000. In return the founder now has 11 paying customers, a tested flow and concrete quotes for investors. That is a far better starting point for building an MVP than an idea praised by friends and family. For a realistic view of time and price for the next step, see our guide to how long it takes to build an app.

Which myths about validation should you watch out for?

• “Our idea is so new that customers cannot imagine it.” Customers can always describe the problem. That is what you test.
• “We will validate once the app is live.” By then most of the money is spent and changes are expensive.
• “Lots of sign-ups means success.” Sign-ups are a good sign. Repeat use and payment are the proof.
• “Validation takes too long.” Four weeks is short compared with the months an app takes to build.
• “We know our customers.” You probably do. The conversations show which of their problems matters most right now.

What do you do once the idea is validated?

Once you have a clear yes, the next step is turning what you learned into a precise scope. That works best in a product discovery workshop, where interviews, prototype tests and pre-sales become a prioritised list of features. Then a first version with the core feature is built for the customers who already said yes. Our app packages start at DKK 28,000 plus DKK 1,200 a month for 12 features and 1 integration, which suits a scoped first version well. For the full price picture, read our guide to what an app costs.

Have you already validated the idea, or do you want help with the prototype? Describe the idea here and you will get a written fixed-price proposal within 24 hours.