What Belongs in a Mobile MVP, and What Cannot Be Deferred

The purpose of a minimum viable product is to learn something before committing further, which means cutting scope aggressively. On mobile, some things cannot be cut without consequences that outlast the experiment.

The distinction is whether a decision can be revised later at reasonable cost. On the web almost everything can. On mobile, several cannot, because your users have to choose to install an update and the store has to approve it.

You cannot fix it silently

A web bug is fixed and everyone has the fix. A mobile bug is fixed, submitted for review, approved, published, and then adopted gradually as users update — with a meaningful tail who do not update for months.

That changes what an MVP can tolerate. A crash affecting a subset of devices is not a same-day fix; it is a week before most users have the correction. Basic crash reporting and a remote configuration mechanism are therefore not gold-plating — they are what lets you respond to a problem without shipping a build.

A remote kill switch for a risky feature is cheap to add up front and impossible to add once you need it.

Permissions asked badly are hard to recover

When a user declines a permission, many platforms will not prompt again, and re-enabling requires navigating system settings. A first-launch request for location, notifications and camera before the user understands the product produces exactly that outcome.

Requesting each permission at the moment it is needed, with the reason visible, is not a polish item. It is the difference between a feature that works and one that is permanently unavailable to a segment of your users because of a decision they made in the first ten seconds.

Account and data model are effectively permanent

Deciding an MVP does not need accounts, and storing everything locally, is a legitimate simplification with a serious catch: users accumulate data on a device. Adding accounts later means migrating that data, handling a user who has installed on two devices with different local state, and doing so without losing anything.

If it is plausible that accounts will be needed, an anonymous identity from the first version — a server-side record the device holds a token for — costs little and turns a migration into an upgrade.

Store review is a schedule dependency you do not control

Review takes days, sometimes longer, and can reject for reasons that are unrelated to your code. Incomplete metadata, a privacy declaration that does not match observed behaviour, a login wall with no demo account, or a payment mechanism the store considers its own.

The last is worth checking early. Platforms have specific rules about what must go through their payment system, and a business model that assumes external payment can be rejected after the app is built. That is not a scope decision; it is a commercial one that needs settling before development.

What is genuinely safe to cut

Onboarding polish. Settings screens beyond the essential. Deep customisation. Offline support, unless offline is the point. Tablet-specific layouts. Localisation, provided the strings are externalised so it is an addition rather than a rewrite. Analytics beyond a small number of events that answer your actual question.

Also worth cutting: platform parity. Launching on one platform first halves the work and gives you a cleaner signal. Choose the platform your target users actually use rather than the one that is cheaper to build for.

What is not safe to cut

Crash reporting. Remote configuration. Sensible permission timing. An identity model that can grow. A privacy policy and store declarations that match what the app really does. A way to contact you from inside the app, because an unhappy user with no route to support writes a review instead.

None of these are large. Together they are perhaps a week, and each one is expensive to add after launch.

Cross-platform is usually right for an MVP

For a product whose purpose is to test demand, React Native or Flutter is generally the better trade. You reach both platforms for close to the cost of one, and if the answer is that nobody wants it, you have spent less finding out.

The exception is a product whose core value depends on a demanding platform capability — sustained camera processing, complex gestures, tight hardware integration. There the cross-platform layer becomes the constraint precisely where the product needs to be strongest, and you would be testing the wrong thing.

The other exception is team fluency. A team strong in Swift and Kotlin with no React experience will ship a native MVP faster than a cross-platform one, whatever the theoretical saving.

Plan the second version before shipping the first

An MVP that succeeds creates immediate pressure to add everything that was cut, usually on a codebase written for speed. That is the point at which teams either pay down deliberately incurred debt or build on top of it.

The useful discipline is recording what was cut and why, as you cut it — a short list of known shortcuts with a note on which will become expensive. It costs nothing during the build and turns an argument in month four into a prioritisation exercise.

The question the MVP should answer

Before building, write down what you expect to learn and what result would change your plan. An MVP that ships and produces a vague sense that people quite liked it has cost you months and told you nothing.

Usually the question is whether people will do the core action repeatedly. That is answerable with a small, unpolished product, provided you instrumented the core action — which is why the small amount of analytics that survives the cut should be exactly that, and not a general-purpose tracking implementation.