MVP Scope Pruning: Must Ship vs Deferred

Definition: MustShip vs deferred is a written scope contract for what an MVP should include — mustShip holds the smallest surface that earns a fair test, deferred parks the rest. We also gate each keep with five states (empty, loading, success, failure, permission denied) and revisit the list at day 14.

Has a week-three “quick add” quietly become your product?

The fastest way to ship is not more hours. It is less surface, done well.

We keep one written list: mustShip vs deferred. It stops scope from growing between demos.

FROM WISH LIST → SHIPPABLE MVP — 4 STEPS

1. 01

   Name the job

   One sentence. One user. Three sentences = three products
2. 02

   List everything

   Then move 80% to “deferred, no apology”
3. 03

   List states

   empty · loading · success — failure · denied
4. 04

   Ship

   User finishes job on prod

if a state has no design → not ready

Cut list — written down, not in Slack

mustShip

auth · core job · checkout · telemetry

deferredForV2

roles · themes · subdomains

Field note — Ankik (MVP ledger → SME product)

We did not need every report on day one. We needed a ledger path people use instead of the notebook — opening balance, clean entry, “where do we stand?” first. Reports came after trust.

Speed comes from cutting scope, not cutting care → smallest shippable surface, highest finishing rate

The four-question framework before code

We run the same four questions with every founder:

1. Name the primary user and the primary job. One sentence. If you need three sentences, you have three products.
2. List every feature request. Then move most of them to deferred without apology.
3. For what remains, list states. Empty, loading, success, failure, permission denied. If a state has no design, the feature is not ready to ship.
4. Define done as a stranger completing the job on production. Not “the happy path works on my laptop.”

Those questions turn a wish list into a fair test — the goal described in our MVP pillar.

Must ship vs deferred — a real example

A founder wants a B2B tool for scheduling field visits. The full vision is maps, offline mobile, custom roles, AI route optimization, and three CRM integrations.

A minimum-care build tries to sketch all of that thinly. A minimum-viable cut ships only the smallest shippable surface:

Must ship	Why it earns a slot
Invite and sign-in	You cannot test retention without identity
Create a job and assign a window	The core job itself
Status updates the customer can trust	Without this, WhatsApp remains the real system
Payment or contract step for the pilot	Answers willingness to pay
Error and empty states on those paths	Protects the validity of the test

Maps, offline, AI routing, and CRM sync wait. Not because they are unimportant — because they do not answer the first question yet. They are priced in the next phase, as explained in our cost breakdown.

This is the same discipline that let Ankik replace scattered notebooks with a single ledger path before we added reports.

The five-state checklist

For every feature that stays in mustShip, we check five states. If one has no design, we pause.

State	Question we answer before shipping
Empty	What do we show when there is no data, and what is the first step?
Loading	What does the user see while we verify in the background?
Success	Is completion obvious and is the next step clear?
Failure	What failed, what is safe to retry, and what was not stored?
Permission denied	Who can help, without exposing internal role IDs?

We treat this as part of engineering, not polish. Our notes on invisible engineering describe why these states matter more than animation on secondary screens.

A copyable scope cut list

We write the list in code so it can be reviewed and versioned:

export const mvpScopeCutList = {
  mustShip: [
    "Core auth and onboarding flow",
    "Primary user job execution",
    "Stripe checkout integration",
    "Basic audit telemetry",
  ],
  deferredForV2: [
    "Complex role-based permissions",
    "Custom theme overrides",
    "Multi-tenant custom subdomains",
    "Deep analytics suite",
  ],
} as const;

The list has two owners and a renewal point at day 14, as shown in how we ship in 28 days. At day 14 we ask: what did we learn, and what now earns a slot in mustShip?

Why we prefer boring structure here

For an MVP, “clever” architecture is a tax. Generic engines and runtime-configurable workflows look senior on a whiteboard and slow every change when the domain shifts.

We prefer explicit flows for the core path, with extension points only where a second real use case has already arrived. That is how a product stays changeable without a total rebuild when the second customer arrives.

Detailed foundations we treat as non-optional — backups with a tested restore, secrets out of the repo, CI on every change, logging to answer “what happened for this user?” — are covered in the pillar.

FAQ — MVP checklist and scope

What should an MVP include? Only the smallest shippable surface that lets a stranger complete one primary job on production — auth, the core path with all five states, payments where money moves, and deploy/telemetry. Everything else is deferred.

What is the five-state checklist? Empty, loading, success, failure, and permission denied — each with a designed copy and next step. If a state has no design, the feature is not ready to ship.

When do deferred items come back? At the day-14 renewal. We ask what we learned from the usable slice and what now earns a slot in mustShip — not what was requested loudest.

Run it yourself: copy the list above, name each job in one sentence, and mark overlap. Want us to run it with you? Map Your Scope to Must Ship vs Deferred — we put it in writing before code and keep the contract visible.