Scoping a mobile MVP: the cut that decides whether it ships
Most first versions fail on scope, not engineering. The useful test is not whether a feature is valuable but whether the product is testable without it.
Key takeaways
- Include only what is needed to learn whether people will use the product at all.
- Error, empty and offline states are part of the minimum; without them early feedback is unusable.
- A multi-screen tutorial usually signals an interface problem that the tutorial hides rather than solves.
- Right-to-left support is architectural; adding Arabic later is a partial rebuild, not a translation task.
A mobile minimum viable product should contain exactly the features required to test whether people will use the thing at all, and nothing else. The right question for each candidate feature is not whether it is valuable, because almost everything proposed is. It is whether you can learn what you need to learn without it. If yes, it is version two.
What almost always belongs
- The core action, done well. The one thing the app exists to let someone do, executed better than the alternative they currently use.
- Whatever authentication that action genuinely requires, and no more. If the core loop works anonymously, ship it anonymously.
- Error, empty and offline states. Not optional. A first version that breaks confusingly on a poor connection produces no usable feedback, only churn.
- Analytics on the core funnel. Without it you launch and learn nothing, which defeats the purpose of launching early.
What almost never belongs in version one
Settings screens with more than two options. Profile customisation. In-app chat. Notifications beyond a single transactional one. Social features, sharing, referral schemes, gamification, and admin dashboards for a user base that does not exist yet. Each of these is defensible in isolation, and together they are why first versions take nine months instead of three.
Onboarding tutorials deserve a specific mention. A multi-screen tutorial is usually a signal that the interface is not self-explanatory, and building the tutorial hides the problem rather than fixing it. If people need instructions to complete the core action, redesign the action.
The two questions that settle most arguments
First: if this feature did not exist, would the core action still work end to end. If yes, it is deferrable by definition. Second: what decision will we make differently based on what this feature teaches us. If nobody can answer, it is not producing learning, it is producing scope.
Bilingual is a scope decision, not a translation task
If your market is Arabic-speaking, deciding to launch English-first and add Arabic later is a genuine architectural choice with a cost. Right-to-left layout affects every screen, and retrofitting it into an interface built without it is significantly more expensive than building for it from the start. Either commit to bilingual in version one or accept that the Arabic version is a partial rebuild.
Set the review date before you start
Agree in advance what you will measure four weeks after launch and what result would cause you to stop, continue or change direction. Teams that do not set this in advance almost always continue, because by then there is a codebase to defend. The point of a minimum viable product is to make stopping a legitimate outcome.
The question is not whether the feature is valuable. It is whether you can learn without it.