A good app idea feels convincing. You can picture the screens, you tell friends about it, everyone likes it. And yet the most important question stays open until real users have the app in their hands: do they install it, do they use it a second time, and are they willing to pay for it?

That question cannot be fully answered in advance. But the risk can be reduced considerably before the whole app is developed. That is what this article is about.

Write down the assumptions

Behind every app idea there are assumptions. Most of them are unspoken. Write them down as simple sentences:

  • Who has the problem? “Restaurant owners with more than one site.”
  • How do they solve it today? “With notes on paper and a spreadsheet.”
  • Why is that not good enough? “Because orders get lost.”
  • Why would they use your app? “Because it is quicker than the paper.”
  • Who pays, and for what? “The business, monthly, per site.”

Any of these sentences can be wrong. Testing means finding out which of them hold - starting with the ones most depends on.

Talk to your future users

The cheapest test is a conversation. Talk to people who have the problem before anything is developed. Do not ask “Would you use this app?” - almost everyone kindly says yes. Ask instead how they solve the problem today, what it costs them and what they have already tried.

People who really have a problem have usually tried something against it. People who have never looked for a solution will probably not go looking for your app either.

Listen especially for the moments when people become animated. And for the ones where they politely agree but ask no questions.

Show the essentials without an app

Before a single line is written, some questions can already be answered:

  • A simple website that describes the app and invites people to join a waiting list. How many sign up?
  • Clickable designs of the most important screens on a phone. Do testers find their way without you explaining anything?
  • Doing it by hand. What the app will later do automatically, you handle yourself for a handful of users at first, by email or phone. That way you get to know the process before you fix it in software.

Not every test suits every idea. But each is far cheaper than an app nobody uses.

Keep the first version lean

At some point development has to start. Then the most important decision is what the first version will not do. People in the trade call it a “minimum viable product” - the smallest version with which users can genuinely use what matters most about the idea.

Lean does not mean careless. The first version has to work reliably, otherwise you are not testing your idea but your users’ patience. Lean means: few features, but good ones.

Typical candidates for “later”:

  • settings and special requests from individual user groups
  • reports in the admin area beyond the bare essentials
  • a second language
  • connections to systems that can be operated by hand at first
  • anything that begins with “it would be nice if”

What matters is a foundation the app can grow on. If you have the first version developed so quickly that it has to be rebuilt from scratch later, you end up paying twice. Ask your developer explicitly what remains of the first version if the idea takes off. How a developer estimates the effort is explained in how a software estimate is made.

Test with real users and evaluate properly

Give the first version to a manageable group of users before you promote it widely. Apple and Google both offer ways to distribute test versions to selected people.

Then look at what users do, not just at what they say:

  • Do they come back? An app that is opened once and then forgotten has a problem no new feature will solve.
  • Where do they drop out? The point where many give up is the most important thing to fix.
  • What do they ask for? Requests that several users make independently belong in the next version.
  • Would they pay? The most honest answer to that question is a payment.

Decide beforehand how you will recognise success. Otherwise every result will find a good explanation after the event.

Adjust the idea or stop

A test rarely confirms an idea exactly as it was. Often it turns out that a different group of users is more interested, that a side feature is what people really want, or that users would pay for something other than expected. That is not failure; it is the point of testing.

Sometimes the test also shows that the idea does not catch on. Then you have found out early and cheaply. That is a result too.

Checklist

  • Are the main assumptions behind the idea written down?
  • Have you spoken to at least a handful of people who have the problem?
  • Do you know how they solve it today?
  • Is it clear what the first version will not do?
  • Have you decided how you will recognise success after the test?
  • Does your developer know the app is meant to grow if the idea takes off?

What happens after the test is described in having an app developed.