The MVP cut list: how to decide what version one won't do

Why MVPs grow out of control

Scope grows because every feature feels small and every request feels important.

A founder hears one prospect ask for an export function, another ask for a mobile app, and a third mention integration with their accounting software. Each one goes on the list. Six months later, the product does twelve things adequately, none of them well, and the money is gone before the first sale. The cause isn't bad judgement on any single feature. It's the absence of a rule for saying no.

The cut list is that rule, written down.

Step 1: Write the one-job sentence

Every scope starts with one sentence that names the buyer, the job and the pain.

The format is: "Version one helps [buyer] do [job] without [current pain]."

Examples:

• "Version one helps independent bakeries take pre-orders for holiday weekends without a phone ringing all day."
• "Version one helps property managers of small rental buildings log maintenance requests without lost texts."
• "Version one helps first-time hobby beekeepers in cold provinces prepare hives for winter without guessing."

If you can't write this sentence from your discovery notes, you're not ready to scope. Go back to the customer interview guide and finish discovery first.

Step 2: List everything, then sort it

Write every feature, function and nice-to-have that anyone has suggested. Then sort each item into one of three columns.

Be strict. A typical first pass puts too much in "must". For each "must", ask: "Could a buyer get the result if this were missing or done manually?" If yes, it's "later".

Step 3: Check every "must" against what buyers said

Each item on the build list should trace back to something in your interview notes.

Next to each "must", write the evidence: "7 of 18 interviewees described losing orders when the phone rang during a rush." If the only evidence is "I think they'll want it", move it to "later". This step usually removes a third of the remaining "musts", and it's the one founders most like to skip.

Step 4: Find what you can do by hand

For the first ten or twenty customers, the founder can often deliver part of the product manually.

Ask, for each "must": could I do this myself, by email, spreadsheet or phone, for the first customers? Common manual-first moves:

• Onboarding done on a call instead of a guided set-up flow.
• Reports compiled by hand each week instead of an automated dashboard.
• Matching or scheduling done by the founder from a spreadsheet.
• Payments taken through a simple invoicing tool instead of a custom checkout.

Estimate the hours. If manual delivery takes two hours per customer per month, that's sustainable for ten customers and not for a hundred. The point is that by the time it hurts, you'll know exactly which part is worth automating, because customers will have told you.

Step 5: Write the success test

Before building starts, write down what a first customer has to do for version one to count as working.

Good success tests are specific and behavioural:

• "Six of the first ten customers pay for a second month."
• "Three bakeries take at least 20 pre-orders each through it over one holiday weekend."
• "Property managers log at least 80% of requests through it within a month of starting."

Bad tests are vague: "customers like it", "good feedback", "traction". Pick one primary test and, at most, one secondary.

A worked example: from twelve features to four

Here's how the method plays out with illustrative numbers.

A founder plans a booking platform for mobile bicycle repair technicians. The original plan has twelve features: booking, deposits, reminder texts, route planning, parts inventory, customer accounts, reviews, a mobile app, a technician marketplace, loyalty points, analytics and accounting export. A builder quotes $72,000 and five months.

Discovery notes from twenty technicians show the main pain is no-shows and last-minute cancellations, which waste a trip and a time slot. The one-job sentence becomes: "Version one helps mobile bike technicians take bookings without losing slots to no-shows."

Sorting:

• Must: booking, deposits, reminder texts, a simple booking page.
• Later: route planning (done by hand for now), customer accounts, analytics, accounting export, reviews.
• Never (for now): marketplace, loyalty points, mobile app, parts inventory.

Suppose the four "musts" are quoted at about a third of the original cost and time, roughly $24,000 and seven weeks. The founder ships about three months sooner, with around $48,000 still available. If the success test passes, say, eight of the first fifteen technicians keep paying after two months, the founder adds features in the order those customers ask for them. If it fails, the founder has lost a third of what the full build would have cost, and still has money to adjust.

Common scoping mistakes

• Building for a pitch. Features that impress in a demo rarely match what a paying buyer needs this month.
• Treating one request as demand. Note it on the cut list with a trigger: "bring back when five customers ask."
• Skipping the cut list. If cut features aren't written down with reasons, they creep back in during the build.
• No manual-first option. Automating a step you've never done by hand means guessing how it should work.
• Comparing quotes on different briefs. Give every builder the same written build list so their numbers mean the same thing.

Using the build list with your builder

Hand the build list, the cut list and the success test to your builder together. Ask them to quote the build list only, to flag anything on it they think is larger than it looks, and to tell you if something on the cut list is actually needed for a "must" to work. That conversation catches most of the surprises before they cost money.

If you'd like us to run this with you, including the builder brief and quote comparison, see MVP scoping. For the next step after scoping, read how to land your first ten customers, or check pricing and call, text or email.