What an MVP is, and what it is not
MVP stands for minimum viable product. Both words matter. Minimum means it carries as little as possible. Viable means a real person can use it to solve a real problem and would miss it if it disappeared. A disappointing MVP usually fails one of the two tests.
An MVP is
- A complete path through one important task
- Built to answer a question about your users
- Small enough to change quickly once you learn
- Finished in what it does, however little that is
- Measured from the first day
An MVP is not
- A full product with half the quality
- A demo that only works when you present it
- Every feature at a shallow level
- An excuse to skip security, privacy or testing
- The first phase of a plan nobody intends to revisit
Start with your riskiest assumption
Every new app rests on beliefs that have not been tested yet. The MVP should be designed to test the one that would sink the product if it were wrong. Find it by writing the assumptions down and asking which you have the least evidence for.
| Assumption | The question behind it | A cheap way to test it |
|---|---|---|
| Demand | Do enough people have this problem and want it solved? | Interviews, a landing page with a waiting list, or selling the service by hand first |
| Behavior | Will people do what the app needs them to do, such as book ahead or enter data? | A clickable prototype tested with a handful of the intended users |
| Willingness to pay | Will they pay, and roughly how much? | Take payment or a deposit before the full product exists |
| Feasibility | Can the hard technical part be done well enough? | A small technical trial of only that part |
| Supply | For a marketplace, can you get providers as well as customers? | Recruit the first providers yourself before building their app |
Some of these tests need no app at all. If an interview or a prototype can answer the question, run that first. It is far cheaper than a release, and it makes the MVP smaller.
Cut the feature list to the core journey
- 01
Write the core journey
One user, from opening the app to getting the result they came for. Five to eight steps is typical.
- 02
List every feature you have imagined
Get all of it onto one page. Nothing is lost by writing it down.
- 03
Sort against the journey
Must means the journey breaks without it. Should means the journey works but feels incomplete. Later means everything else.
- 04
Look for work a person can do instead
In a first version, your own team can often do by hand what software will do later, such as matching, approvals or reports.
- 05
Buy what is not your product
Sign-in, payments, maps and messaging are solved problems. Use established services for them.
Cutting the list for a home cleaning booking app
The product and the decisions are invented to show the method.
| Feature | Decision | Reason |
|---|---|---|
| Choose a service and a time | Build | This is the core journey |
| Sign in with a phone number | Build | Needed to hold a booking, using an existing sign-in service |
| Card payment | Build | Tests willingness to pay, using a payment provider |
| Booking reminders | Should | Notifications are simple to add once bookings exist |
| An app for cleaners | Later | The team assigns jobs by phone while volumes are low |
| Ratings and reviews | Later | Needs volume to mean anything |
| Referral codes | Later | Growth comes after proof that people rebook |
| Admin dashboard | Minimal | A simple list of bookings, with reports done in a spreadsheet |
Eight features become three to build, one that should follow and one minimal tool for staff. The first version can now answer the question that matters, which is whether customers book a second time.
Decide what success looks like before you build
If you choose your measures after launch, any result can be made to look good. Write them down first, with the level that would count as a pass, and build the analytics to capture them.
| What you want to know | A measure | Where it comes from |
|---|---|---|
| Do people get started? | Share of new users who complete the core journey once | Analytics events on each step of the journey |
| Do they come back? | Share of users who repeat the journey within your natural cycle | Analytics, by weekly or monthly groups of new users |
| Where do they give up? | The step with the largest drop | A funnel report across the journey |
| Would they miss it? | What users say when asked how they would feel without the app | Short interviews or an in-app question |
| Does the business work? | Revenue per booking against the cost of serving it | Payment data and your own records |
Choose a build approach that fits an MVP
For a first version, speed of learning matters more than technical perfection. Cross-platform development with React Native or Flutter often suits an MVP, because one codebase reaches both iPhone and Android. Native development is the better choice when the product depends on device features or on the finest feel. Our comparison of native and cross-platform development sets out the trade-offs.
Keeping the scope small does not mean cutting corners everywhere. Some things are cheap to do properly at the start and costly to add later.
Do not cut these
- Secure sign-in and sensible handling of personal data
- Analytics on the core journey
- Crash reporting
- Store requirements, including a privacy policy and account deletion
- A written agreement on who owns the codebase and the store accounts
If you are unsure whether a first version or a fuller product is right, see MVP vs full product.
MVP planning checklist
Before you ask for a quote
0 of 9 checkedAfter launch, act on what you learn
- 01
Watch real use
Look at the funnel and at recordings of where people hesitate, before you look at opinions.
- 02
Talk to users
Speak with people who came back and with people who did not. The second group teaches more.
- 03
Decide
Continue and invest where the measures passed, change direction where they did not, or stop if the core assumption proved false.
Stopping is a legitimate result. An MVP that shows an idea does not work has saved the cost of the full product.
What to do next
Work through the checklist, then turn the must list into a short document. How to write a mobile app requirements document has a template for it.
If you would like a team to plan the first version with you, our startup MVP development page explains how we scope and build one, and mobile app development covers the build itself. Or send us your feature list and we will tell you what we would cut.
Common questions
How long does it take to build a mobile app MVP?
It depends on the core journey, the number of user roles and what the app must connect to. A proposal should state the timeline once the scope is agreed. If the estimate feels long, the usual cause is a must list that is still too large, and the answer is to cut features, not to rush the build.
How many features should an MVP have?
As many as the core journey needs, and no more. For many apps that is one complete journey for one kind of user, plus sign-in and whatever staff need to operate the service. Counting features matters less than checking that a user can get from start to result without leaving the app.
Can I build an MVP with a no-code tool?
Sometimes, and it can be the right choice for testing demand. No-code tools work well for simple apps built from forms and lists. They become limiting with custom logic, offline use, performance needs or deeper integrations. Decide knowing that a successful test may be followed by a rebuild.
Is it risky to launch something so small?
A small product that works is safer than a large one that half works. Users forgive a narrow scope when the one thing the app does is done well. They do not forgive lost data, crashes or a confusing journey, which is why quality on the core path is not what you cut.
What happens to the MVP code afterwards?
If it was built properly, it becomes the base of the product and is extended. If speed was bought with shortcuts, part of it may be rewritten once the idea is proven. Ask the company at the start which parts are built to last and which are deliberately temporary.
