How to cut an MVP scope without cutting the product

Your feature list is three pages long and the estimate that came back is more than you wanted to spend. Everyone says "cut scope", and nobody says which parts. This post is about how to make that cut so that what remains is a product someone will use, rather than a smaller pile of features.

Three things people call an MVP

The phrase covers three different objects, and a lot of scope arguments are really a disagreement about which one is being built.

A demo is a slideshow that happens to be clickable. A prototype exists to answer a question ("will coaches enter their own availability?") and can be thrown away once it has. A first version is software you run in production for strangers. Decide which one you are buying before you cut anything, because the cuts are different. You can strip a prototype down to a single screen. You cannot strip password reset out of a first version.

Most of what follows is about the first version.

The one-workflow rule

Pick the one thing a user does that, if it works, makes the product worth paying for. Build that workflow from the first click to the last, including the boring parts: sign-up, the empty state, the confirmation email, what happens when they come back tomorrow. Then stop.

One workflow that a user can complete on their own, without you on a call, beats five features that each need a walkthrough. It is also the smallest thing you can charge for, and charging is the only feedback that cannot be polite.

The test is simple to state and uncomfortable to apply: can a new user go from hearing about the product to getting the thing it promises, alone, today? If any step needs you, that step is still in scope. If a feature does not sit on that path, it is not.

What founders ask for first, and should defer

These come up in almost every first conversation. Each is reasonable. Each is also a version-two item, and the reason is the same: it multiplies the surface area of everything else.

An admin dashboard. You are the admin, and for the first months you can look at the database directly, or at a plain table. A dashboard with charts is built once you know which numbers you look at every day. Before that you are guessing which charts to build.

Roles and permissions. "Owner, manager, staff, read-only" sounds like a small matrix. It is a test case for every screen. Start with one kind of user plus you. Add the second role when a real customer asks for it and can tell you exactly what that person is not allowed to see.

Native mobile apps. Two more codebases, two app-store review processes, and a release cycle you do not control. A responsive web app that works on a phone gets you to the same users. Build native when you need the camera, offline use or push notifications badly enough to pay for it, and when the web version has proven people want the product.

Integrations. Each connection to a calendar, an accounting package or a CRM is a small product of its own, with someone else's API changes to track. Ship with CSV export and a webhook. Build the integration a paying customer names.

Multi-tenancy and white-labelling. Every customer with their own subdomain, branding and settings. Necessary once you are selling to organisations; expensive before you have one.

Multiple languages and currencies. Unless your first ten users speak different languages, launch in one. Internationalising later is a known chore; doing it first is a tax on every string and every date.

What founders under-scope

The opposite list. These are rarely on the feature list, and they are the reason a "two-week build" takes six.

• Authentication edge cases. Password reset, email change, a locked account, sign-in from a second device, a user who signs up twice with different capitalisation. None of it is exciting. All of it is on the one workflow.
• Email deliverability. The confirmation and reset emails have to arrive, which means a sending domain with SPF, DKIM and DMARC records, a transactional email provider, and a plan for bounces. "We'll send from Gmail" is not a plan.
• Payment failure paths. A declined card, a card that expires mid-subscription, a refund, a dispute, a customer who downgrades on the last day of the month. The happy path is a morning; the failure paths are the week.
• Data export and deletion. Users will ask for their data, and under UK GDPR they can. Build the export on day one; it is trivial then and painful later.
• Backups, and a restore you have tried. A backup that has never been restored is a hope. Schedule one and test it before launch.
• The empty state. A new account with nothing in it. Most products look broken here, and it is the first thing every user sees.

Put these in the estimate explicitly. If a team's quote does not mention any of them, ask where they went.

A worked example: a session booking tool

Take a generic product: a tool for a small sports club that lets members book coached sessions. The founder's list runs to about thirty items. Here is how the cut goes.

The one workflow. A coach publishes next week's sessions; a member sees them, books a place, receives a confirmation email, and can cancel up to a cut-off. That is the product. If it works, members stop messaging the coach on WhatsApp, which is the problem the club has.

In the first version:

• Sign-up and sign-in for members, with password reset.
• One club, one coach account (the founder), sessions with a date, capacity and a price.
• Booking, cancellation with a cut-off, and a waiting list that promotes the next person automatically.
• Card payment per booking with a declined-card path and a refund on cancellation.
• Confirmation and reminder emails from the club's own domain.
• A plain list view for the coach: who is booked on what. No charts.
• Nightly database backup with a documented restore.
• Export of a member's bookings as CSV.

Deferred, with the trigger that brings each one back:

Notice that every deferred item has a trigger that is an observation, not a date. The list is the road map; the triggers are what stop you building it in the wrong order.

How to run the cut in a meeting

Print the feature list. For every line, ask two questions: is it on the one workflow, and what breaks if we ship without it? Anything not on the workflow moves to the deferred column with a trigger. Anything that "breaks nothing" moves there too. What is left is the first version, and it is usually a third of the original list plus five things that were never on it.

Then get an estimate for that, and a separate rough figure for the deferred column, so nobody pretends it went away.

What to do next

If you have a feature list and want a second opinion on the cut, send it through the contact form with a sentence about who the first users are. We reply within two working days with the version of the list we would build first, and why.