MVP scope: what to build first, what to cut
The fastest way to blow an app budget is to build the full vision on day one. Scoping the MVP is deciding, deliberately, what to leave out.
An MVP is the smallest version of your app that delivers the core value once, well enough that your target user comes back. To scope it, identify the single core loop your app exists to serve, build only what that loop needs, and defer everything else. The discipline is subtraction: a "simple app" becomes a six-figure build when nothing gets cut.
An MVP is not a smaller version of everything. It is the whole of one thing — the core value — and nothing else yet.
What an MVP is and isn't
A minimum viable product is the least you can build to test whether people want the core value and will return for it. It is not a prototype (which tests an idea without real code) and it is not a stripped, broken version of the full vision. It should do one thing genuinely well rather than ten things poorly. The point is to learn from real users as cheaply as possible, then invest in what the evidence supports.
Find the core loop
Every app has a core loop — the sequence a user repeats to get value. For a ride app: request, match, ride, pay. For a habit tracker: prompt, act, log, see progress. Identify yours, because it is the one thing the MVP must nail. Everything that supports the loop is in scope; everything else is a candidate to cut. If you cannot state your core loop in one sentence, that is the first thing to fix.
The must / should / could / won't cut
Sort every feature into four buckets:
- Must-have — the core loop cannot work without it. This is your MVP.
- Should-have — important but the loop works without it. Fast-follow.
- Could-have — nice, not necessary. Later.
- Won't-have (yet) — explicitly out of scope for now.
The hard, valuable work is being honest that most features are not must-haves. Nearly everything feels essential in your head; the bucket exercise forces the real priority to surface.
What to almost always defer
Common v1 cuts that rarely hurt and usually save real money:
- A second platform. Launch on one, validate, then expand.
- Extensive settings and customization. Sensible defaults first.
- Admin dashboards and analytics UIs. Use existing tools early.
- Social features, gamification, and integrations that sit outside the core loop.
- Edge-case features that serve a small fraction of users.
What you can't cut
Some things are not optional even in an MVP: the core value itself, a first-session experience good enough that users reach that value (a broken onboarding invalidates the whole test), and the baseline of trust — reasonable security, privacy, and reliability. Cutting these doesn't make a leaner MVP; it makes an invalid one, because users churn for reasons that have nothing to do with your idea. Related: activation and retention.
Signs you're overscoping
You are probably overscoping if the feature list keeps growing, if "we might as well add it while we're in there" appears in planning, if the build timeline stretches past a few months for a first version, or if you cannot describe the MVP in a sentence. Each is a signal to return to the core loop and cut back to it.
From MVP to roadmap
Cutting is not deleting. Everything you defer becomes your roadmap, sequenced by what you learn from real users after launch. That is the payoff of disciplined scoping: you ship sooner, spend less, and let evidence — not assumption — decide what to build next. The full context is in planning an app, and the cost impact is in how much it costs to build an app.