Most app ideas start large. A list of features grows in a notebook, each one sensible, until the plan describes a product that would take a year to build. The safer path is to build less first. That smaller first version is called an MVP, and for most businesses it is the right way to start.
What MVP means
MVP stands for minimum viable product. It is the smallest version of your app that real people can use for its main purpose, and that tells you whether the idea works.
Each word matters. Minimum means it does one job, not ten. Viable means it does that job properly: it works, it is secure, and people can use it without help. Product means it is real and in people's hands, not a drawing or a demonstration.
Think of a restaurant that starts as a food stall. The stall serves three dishes, not thirty. If people queue for them, you have learned something worth knowing before you sign a lease.
Why your first app should be one
It costs less. A smaller app takes less time to design, build, and test. The money you save can go into the second version, once you know what it should contain.
You learn sooner. The most valuable thing a first app gives you is evidence. You find out which features people use, which they ignore, and what they ask for that you never thought of. An app that takes a year to build gives you that evidence a year later.
It reaches people sooner. Every month spent building is a month nobody is using it. Apple and Google also review apps before they appear in their stores, so a smaller first version is quicker to get through that step as well.
Deciding what goes in
Start with three questions, and write the answers down.
- Who is it for? Name one kind of person, such as "regular customers of our café", not "everyone".
- What one problem does it solve for them? For example, "ordering ahead so they skip the queue".
- What has to happen for it to count as a success? For example, "a hundred people order through it more than once in the first two months".
Every feature on the list then faces one test: whether the app fails at its one job without it. Ordering and paying pass. A loyalty scheme, a chat feature, and a dark mode can wait for version two.
Minimum does not mean poor
An MVP is small, not careless. It should be secure, reliable, and pleasant to use, because people judge an app in the first minute. A clumsy first version teaches you only that people dislike clumsy apps.
The cuts come from the feature list, not from the quality. Fewer screens, each one done well, beat many screens done badly.
Building for both phones at once
Most businesses need their app on both iPhone and Android. Building two separate apps doubles the work. We build with Flutter, Google's toolkit for writing one app that runs on both, so an MVP reaches both stores from a single build.
After launch
Launch is where the useful part starts. Use analytics, the anonymous figures that show how people use the app, to see what they actually do. Talk to a handful of users. Then compare what you find with the success you wrote down at the start.
Some features will prove themselves, and some will not be missed. The second version is built on that evidence rather than on guesses, which is the whole point of starting small.
If you have an app idea and want help deciding what belongs in the first version, get in touch.
Glossary
- MVP (minimum viable product): the smallest version of an app worth putting in front of real users.
- Feature: one thing an app lets people do, such as ordering, paying, or messaging.
- Prototype: a clickable model of an app used to test ideas before it is built. Unlike an MVP, it is not a working product.
- Flutter: Google's toolkit for building one app that runs on both iPhone and Android.
- App store review: the check Apple and Google make before an app appears in their stores.
- Analytics: anonymous figures that show how people use an app, such as which screens they visit.
- Version two: the next release, built on what the first one taught you.