Scoping an MVP: The One Question That Cuts 80% of Your Feature List

Almost every first-time system owner watches their feature list grow and grow: "Since we're building anyway, let's throw in reports." "We'll need it eventually — build it now." Our experience is brutal: of the features crammed into a first version, eighty percent go untouched after launch. Every "while we're at it" is real development hours, and worse, it pushes out the launch date — the market doesn't wait. The complete version you spend eight months building could have been a three-month lean version already taking orders and learning. The whole discipline of an MVP (minimum viable product — the smallest possible first version that still solves the core problem) is cutting.

One question that cuts 80% of features: can you launch without it?

When we help clients converge scope, we use exactly one knife. For every feature on the list, ask: "Without this, can the system not launch?" Note — the question is not "is this feature useful?" Almost every feature is "useful"; ask that and you'll never cut anything. The question is "without it, does the core flow break on day one?"

Take an order-taking system as an example: customer places order, store receives it, goods ship, payment collected — break any link in that chain and you can't launch. That's the MVP. What about "member tiers"? Day one without member tiers, orders still come in, goods still ship — so no. "Automated reconciliation reports"? Order volume is small for the first three months and manual reconciliation holds up — so no. Being cut doesn't mean never built; it means scheduled for version two. And once real usage feedback arrives, you'll find half of your imagined v2 list gets replaced by actual demand. That's a good thing: you spend money on features you know people want.

MVP does not mean a rough version

A common misreading of MVP is "build something crappy first." Wrong. MVP means small scope, not low quality. Everything inside the scope must be solid: payments can't drop orders, inventory can't miscount, data can't be lost. We operate an inventory-management SaaS ourselves; its v1 feature list was cut ruthlessly, but every flow that survived is guarded by automated tests — because franchise stores run on it daily, and the trust cost of one wrong ledger entry far exceeds the cost of one missing feature.

The other place people cut wrongly is the "foundation": backups, baseline security, a data structure that can grow. Users never see these, so they get filed under "later" — but they're among the few things that cost ten times more to retrofit than to build now. Cut features boldly; cut foundations very, very carefully.

The spirit of an MVP isn't saving money — it's minimizing the cost of guessing: the smallest possible investment traded for a real answer from the market.

How to sort the first version with your team

In practice we walk clients through one round of triage, dropping every feature into four buckets:

1. Can't live without: the business can't operate if the core flow breaks. This is version one.
2. Needed soon: things that collapse under volume within one to three months of launch (e.g., automating manual reconciliation). Scheduled for v2, but architecturally provisioned for now.
3. Want: sounds nice, no data behind it. Frozen until post-launch data speaks.
4. Don't actually need: usually an idea copied from someone else's system. Delete it outright — don't even keep it on a list, or it resurrects at every meeting.

After sorting, look at bucket one's quote and timeline. Over budget? Go back and cut another round — yes, bucket one usually still hides bucket-two items. This process hurts, but remember: every feature that stays in version one is delaying your launch and delaying your learning.

After the cut, defend the scope

Once scope has converged, the biggest enemy is mid-development "just quickly add this." Our practice: the cut features go, in black and white, into the spec document's "not included in this phase" list, and any new idea that surfaces during development goes straight onto the v2 list without interrupting the current sprint. It sounds cold, but holding the scope is how you hold the timeline and the budget — and that's the most practical protection a client can get.

If you're holding a feature list that's spiraling out of control and aren't sure what belongs in version one, bring the list and talk to us, or see how we do scope planning in our custom systems and SaaS services. Cutting scope is one of those things outsiders see clearly — and we've done it many, many times.