Umvix
All posts
Mobile AppsMVPProduct

MVP scope for a mobile app: the flows that matter

Most first versions are too big. A practical method for cutting an app to the flows that prove the idea, without shipping something nobody can use.

Umvix Team 2 min read
Share

Every founder we meet has a feature list. Almost none have a flow list, and the flow list is what actually gets estimated, built, and used.

Features versus flows

A feature is "push notifications". A flow is "a customer gets notified their order shipped, taps the notification, and sees the tracking screen".

Flows are testable, estimable, and demonstrable. Features are aspirations. Rewrite your list as flows and it usually shrinks by half on its own, because several features collapse into one journey.

The flows a first version needs

Almost every consumer or B2B app MVP needs roughly these:

  1. Get in. Sign up, log in, recover a forgotten password. Boring, non-negotiable, and consistently underestimated.
  2. See the thing. The core list or feed — whatever your app is fundamentally about.
  3. Do the core action. Book, order, post, message, track. This is your product. Everything else is support.
  4. See the result. Confirmation, status, history. Users need proof their action worked.
  5. Be told something changed. One notification path, not a notification system.
  6. Get help. A support route. A mailto link counts.

Five to eight flows total. If you have twenty, you are not building an MVP — you are building version three and calling it version one.

What to cut from version one

  • Social features. Comments, likes, following. They need a user base you do not have yet.
  • Multiple roles. Every additional role roughly multiplies testing. Ship for your primary user first.
  • Settings screens. Sensible defaults beat a preferences panel nobody opens.
  • Onboarding carousels. If the app needs three explanatory screens, fix the app.
  • A web dashboard "while we're at it". That is a second product.
  • Offline-first. Genuinely hard, genuinely expensive, and rarely what makes v1 fail.

What never gets cut

Some things look like polish and are not:

  • Error and empty states. A new user's first screen is always empty. That is your only chance at a first impression.
  • Analytics. Shipping an MVP with no instrumentation means you learn nothing from it, which defeats the point.
  • Crash reporting. You will not hear about crashes from users; they just uninstall.
  • A way to contact you. Your first hundred users are your research.

The test that settles arguments

For every proposed feature, ask: if we ship without this, does the app still prove or disprove our core assumption?

If yes, cut it. If the room cannot agree on what the core assumption is, stop scoping and settle that first — it is the real problem.

What this means for budget

A tight five-to-eight-flow MVP typically lands in the $5,000–$12,000 band for one platform, or the lower end of $15,000–$35,000 cross-platform with a real backend. The same idea with twenty flows does not cost twice as much; it costs three times as much and takes four times as long, because complexity compounds through testing.

Before you submit, run through the App Store rejection checklist — half of it is scope decisions you make now.

Send us your flow list — not your feature list — and we will tell you which flows we would cut and what the remainder costs.

Keep reading