How to Scope an MVP So It Actually Ships

The number one reason MVPs don't launch isn't bad code — it's scope. The feature list grows until shipping feels impossible. Here's how to cut it down to something that actually goes live.

Find the one loop

Every product has a core value loop. For a marketplace: list → buy → money moves safely. For a meal service: see today's menu → join → get fed. Identify yours, and recognize that everything not on that loop is, by definition, deferrable for v1.

Sort features into "spine" and "later"

Take your feature list and mark each: is this part of the core loop (spine) or an enhancement (later)? Notifications, dashboards, referral programs, settings pages — almost always "later." Be ruthless. The discomfort you feel cutting them is the feeling of an MVP getting shippable.

Define "done" for v1 as the loop working end-to-end

Not pretty. Not feature-complete. The core loop functioning from start to finish with real data. Ship the spine, then flesh it out. A working ugly loop teaches you more than a beautiful disconnected screen.

Protect the money path

If your loop touches payments, that part doesn't get the "rough is fine" treatment. Everything else in v1 can have edges; the part that moves money must be solid. That's the one exception to "ship it rough."

Set a launch date and cut to fit it

Pick a date. Then cut scope until the spine fits. A date forces the prioritization that endless backlogs avoid. The features you cut aren't gone — they're v2, informed by real users.

Takeaway

One loop, spine vs later, done = loop works end-to-end, money path solid, date drives cuts. That's how an MVP stops being a someday project and becomes a live product.

Got an idea stuck in scope? Let's get it shipped.