The idea started with an order screen and a tracking screen. Three meetings later, the list included in-app chat, a points program, ratings, two languages, three payment methods and a detailed reporting dashboard. The budget doubled, the launch date moved further away, and no real customer had tried anything yet. Every extra feature also means more screens to test, more questions from store reviewers, and more maintenance after launch. This happens on a lot of projects, and the fix is to decide what the first version needs before building starts.
What is an MVP for a mobile app?
MVP stands for Minimum Viable Product: the smallest version of the app that fully solves the main problem for one type of user. It is released to real customers, and the goal is to learn from them what they really use before you spend money on the rest.
It has few features, and each of them works from start to finish with nothing missing.
How do you define your app's core task?
Write it in one sentence: "[This user] can [do this] without [this problem]." For example, a laundry customer can request a pickup from home without calling and explaining the address every time. Any feature that directly serves that sentence is a candidate for the first version, and everything else waits.
Here is another example, from internal operations: a technician can close a maintenance job with photos and the customer's signature without going back to the office. Notice that the sentence names one user. Apps that serve several parties usually start with one of them, and the others are handled for now from the admin panel or by phone.
If you can't write the sentence, the problem lies in the idea itself, and it needs some thinking time before any design work.
What should you build in the first version?
- The core flow from start to finish, with no missing step.
- Simple sign-in by phone number or email, with the option to delete the account from inside the app, as Apple requires.
- A web admin panel with as much as your team needs to run the service day to day.
- Notifications for the core flow only, such as order confirmation and status changes.
- A crash reporting tool and basic analytics that show you where users drop off.
- A privacy policy and a support page, because both stores require them.
What can you postpone until after launch?
| Feature | In the first version | Later |
|---|---|---|
| Support chat | A button that opens WhatsApp | In-app chat |
| Payments | One or two methods most of your customers use | Wallets and extra methods |
| Reports | The numbers you need each week | Detailed dashboards and exports |
| Loyalty and points | A simple discount code | A full points program |
| User types | The customer, with management on the web | A separate app for drivers or service providers |
The items in the last column are useful, and they can wait until you see real usage. Every feature you postpone lowers the upfront cost and shortens the road to your first real user. We explain the effect on price in the factors that set an app's cost.
What are the stages of building an MVP?
- Define the scopeThe core task and a list of what goes in and what waits
- Design the screensA clickable prototype customers try before coding
- BuildThe app, the admin panel and the integrations
- Closed testWith a small group of customers
- LaunchPublishing in both stores
- Measure and improveBased on what people actually use
The closed test matters for publishing too, because Google Play currently requires a closed test for new personal accounts before a public release. The details are in publishing an app on the App Store and Google Play.
What are the common MVP mistakes?
The first is a version so small that it solves nothing, or one full of bugs with the excuse that it is a "trial." Users don't know it is a first version and judge it like any other app, and Apple rejects apps that look incomplete.
The second is building apps for every party at once, the customer, the driver and the service provider, before confirming that the customer will even use the service. The third is launching without any measurement, so a month later you have no idea where people stop or why.
What should you do after the first version launches?
Watch where users leave the core flow, read the store reviews and support messages, and ask ten customers about their experience directly, by phone or face to face, since conversations reveal things the numbers don't. Then rank the postponed features based on what you learned. Some will become urgent, and nobody will ask for others.
Keep updates regular in the first months, every two or three weeks for example, with small improvements based on what you saw. That works better than waiting six months for one big update, because you can see the effect of each change clearly and fix mistakes while they are small.
We help scope and build first versions as part of our mobile app development service. Send us the feature list you have in mind, and we'll suggest what goes into the first launch and what can wait.
Questions our partners ask
Does a first version mean a low-quality app?
No. It means fewer features, each built to full quality. An app that crashes or looks unfinished gets rejected by the stores and loses users on their first try.
How long does a first version take?
It depends on the number of user types and the integrations with other systems. A well-defined scope gets done in a few weeks or months, while an open-ended list drags on with no end date.
Should I launch on iOS and Android at the same time?
In Jordan and Saudi Arabia your customers usually use both, and building with one codebase makes launching on both together the sensible choice in most cases.
Written by the Visual Innovate team, the people who build, host and follow up systems, websites and apps for our clients in Jordan, Saudi Arabia, Oman and Egypt.
