How to Test an App Idea: Start with a Small First Version

Everyone with an app idea pictures it in its most complete form. Membership, a points system, promotions, in-app chat, multiple languages and detailed reports are added to the list one by one. As the list grows, so does the excitement. But every new feature pushes the launch date a little further back and takes a little more of the budget. On top of that, there is no way to know before launch how many of these features will actually be used.

In this article we describe a different path: first testing the idea with a small first version (MVP) that works with only the core features, then growing it based on how real users respond. This approach applies both to entrepreneurs building a new product and to businesses that want to bring their work to the phone. The goal is to spend most of the budget and time on features that have been shown to work.

What a first version is, and what it isn't

A first version means launching the app in the smallest form that does its main job. For a restaurant, the main job is letting the customer see the menu and place an order. For a hair salon, it is booking an appointment. For a field team, it is seeing the day's jobs and marking them as done. The first version does this job completely and without problems; everything else waits until later.

A first version is not a careless or half-finished app. It offers few features, but it does the features it offers well. An app that is full of bugs, slow or confusing tests the app itself, not your idea. When users give up, you cannot tell whether it was because of the idea or because of a poorly built app. That is why what you cut in the first version is the number of features, not the quality.

Why is starting small smarter?

• Your money isn't spent on features nobody needs yet. Users show you which features are really wanted.
• You launch sooner. Instead of growing the idea on paper for months, you reach real users in much less time.
• You spot wrong assumptions early. Learning early that your customers use the app differently than you expected keeps you from growing in the wrong direction.
• Testing and maintenance are lighter at the start. Fewer features mean fewer chances for bugs.
• You get to know your users early. Feedback from your first users lets you develop your product together with them, and these people can become loyal customers over time.

How do you decide what goes into the first version?

Take your feature list and write a single question next to each item: Without this feature, can the user still do the app's main job? If the answer is “no”, the feature goes into the first version. If the answer is “yes, but it would be a bit of a hassle”, it can most likely wait. If the answer is “this would be a nice extra”, it definitely waits until later.

Let's go back to the restaurant example. The menu, the cart, placing an order and a message that reports the order status go into the first version. Loyalty points, promotional coupons, support for multiple branches and detailed sales reports can be added once it is clear that users are actually using the app. This split can bring your launch date noticeably forward and lets you save most of your budget for the second stage. The logic is the same for a product sold by subscription. Membership, the core service and payment go into the first version; detailed settings and add-on packages wait until later.

Think about your first users from the start

The value of a first version comes from the people who actually use it. If you have a business, your first users are customers you already know. You can mention the app at the checkout, with your delivery orders or on your social media account. If you are an entrepreneur, starting with a small group from your target audience and talking to them regularly teaches you more than a large number of random downloads. You can also try the app with a limited group before opening it to everyone; both stores offer testing options for this.

What should you look at after launch?

The purpose of the first version is to learn. That is why you should decide from the start what you will measure after launch. The number of downloads alone is misleading, because someone who downloads the app, opens it once and leaves it does not tell you much. What you really need to look at is whether people come back to the app and whether they do the main job. In the restaurant app, that means second and third orders. To see this information, simple usage tracking should be built into the app from the start; adding it later means missing the data from the first weeks. These questions will guide you:

• Do users open the app again a week later?
• Can they complete the main job (an order, an appointment, a sign-up) from start to finish, or do they leave it halfway?
• Which requests or complaints keep coming up in store reviews and in the messages you receive?
• On which screen do users get stuck most often?

As answers to these questions build up, the list for the second version takes shape on its own. You now have a roadmap based on real user behavior rather than guesses. When planning the second version, keep asking the same question: Does this feature make the user's main job easier?

Traps to avoid when starting small

Keeping the first version small should not mean writing it like a draft to be thrown away later. The app's foundation should be built so that it can carry the features added later. Otherwise, you may have to rewrite the app from scratch when it is time to grow. The second trap is narrowing the first version so much that the app is of no use to anyone. The right measure is this: the app should do one job completely, in the way the user really needs it. The last trap is ignoring the signals that come from the first version. If users are heading in a different direction than you expected, changing the plan is not a failure; it shows the first version did exactly what it was meant to do.

Ask yourself these questions before you start

• What is the single most important problem my app solves?
• Which features are essential to solve this problem?
• Who will my first users be, and how will I reach them?
• After launch, which signals will I look at to decide whether to continue or to change course?

If you have answers to these questions, you are in a good position to turn your idea into a working app. At Adorb, we follow exactly this path with entrepreneurs who have a product idea and with businesses that want to bring their work to the phone: we simplify the idea together, map out the right first version, start small and grow with the users.