The scope cut: what goes in your MVP
It is late, and she has the folder open again.
Inside it are the documents she has been writing for a year. Feature ideas, flows sketched on the train, screenshots of competitors with notes in the margin, a list headed "phase two" that is longer than the list headed "phase one". She has raised money on the strength of this idea. She has told people it is happening. Tomorrow she has a call with the people who are going to build it, and they have asked her one question to think about beforehand.
If you could only launch with one thing, what would it be?
She has been staring at the question for an hour, and every answer feels like a betrayal. The matching is the product, obviously. But without the reviews nobody will trust the matching. And without payments inside the platform, people will just swap numbers and leave. And the messaging, surely people need to message. And the thing she is proudest of, the part that made an investor lean forward, is on page four of the phase two list.
She closes the folder and writes back: all of it is essential, honestly.
What should go in an MVP?
The short answer: one complete loop. An MVP, the first version of a product, should contain the single repeated action a customer comes for, such as finding a provider and booking them, plus only what that loop cannot run without. Everything else is done by hand for now, or dated for later. Nothing is thrown away.
That is how we scope every first version at Speed Systems, where we build products for founders. The rest of this piece is why the answer is so hard to accept, and how to make the cut.
What is really being decided when you scope an MVP?
Almost every founder we speak to arrives at the moment in that scene, and most arrive with the same answer. It is the most common question on our first calls: what actually goes in the first version, and what waits?
On the surface it looks like a planning question. Which features, in what order, at what cost. That is the part a builder can help with, and it is the easy part.
Underneath it is a different decision, and it is not technical at all. Every feature in that folder is a small promise the founder has made, to investors, to early users, to herself. Cutting a feature feels like breaking one. The folder is not a backlog. It is a year of hope written down, and she is being asked to leave most of it behind.
That is why the scope cut is so hard, and why it is so often avoided. Founders do not overbuild the first version because they cannot prioritise. They overbuild it because every cut feels like admitting the idea is smaller than they said it was.
Why do founders put everything in version one?
It is worth being fair to the founder who says everything is essential. She is not being naive. She is reasoning from real fears.
She is afraid that a thin product will be judged as the whole product, and that first impressions do not come twice. She is afraid that a competitor will launch the complete version while hers is still missing half its parts. She is afraid, often correctly, that her investors expect to see the thing she pitched. And she has usually read enough to know that "launch small" is advice given by people who are not risking their own money.
Every one of those fears is sensible. The trouble is what they add up to. A first version built to answer every fear takes longer, costs more, and teaches less, because when it finally launches there are so many moving parts that nobody can tell which one worked. The biggest risk to a new product is not launching too small. It is spending the whole budget before learning the one thing that decides whether the idea works.
How do you cut an MVP scope?
When we scope a first version with a founder at Speed Systems, we do not start from the feature list. We start from the loop. It is the first step of every build we run, and it happens before any code is written.
Find the one loop. Every product that works has a single repeated action at its heart: a customer finds a provider and books them; a candidate is assessed and matched; an order is placed and fulfilled. Everything else in the folder is either part of that loop, or around it. The first version is the loop, complete, and as little as possible around it.
Ask four questions of every feature.
- Does a customer need this to complete the loop at all?
- Would a paying customer notice, in the first month, if it were missing?
- Can it be done by hand, by the founder, until the volume says otherwise?
- Is it here to answer a user's need, or a founder's fear?
Anything that fails the first two waits. Anything that passes the third starts as a manual process: the founder checks the documents, sends the reminder, approves the listing herself. It is slower and less impressive, and it is the surest way to learn what the automated version should actually do. The fourth question is the uncomfortable one, and it is usually the most useful.
Write three lists, not two. Now is the loop and what it cannot run without. Next is what the loop will ask for once real people use it. Later is everything else, kept, dated and visible, so cutting a feature is a decision about timing, not a rejection. Founders let go much more easily when they can see where the idea went.
Tie changes to the launch date, not the budget. During the build, new ideas will keep arriving; that is a good sign. Each one goes on the next list and is weighed against the date, not squeezed in. When every new idea has to answer "is this worth moving launch for?", most of them wait on their own.
Build for the device people will actually use first. For most first versions, that means a web app that works well on a phone before a native app in the stores. A native version later is a new code base, not a new product: the flows, the decisions and the design carry over. What the founder learns in the meantime is the valuable part.
Who decides what goes in the first version?
A builder can map the loop, cost the options and show what can be done by hand. What a builder cannot do is make the cut. That belongs to the founder, because it is not a technical choice. It is a choice about which promise to keep first.
The first version is not a smaller copy of the whole product. It is the one thing a paying customer would miss, built properly, and the courage to leave the rest for later.
The founders who do this well are not the ones with the least ambition. They are the ones who can hold the whole idea in their head and still point at one part of it and say: this, first. They trust that the rest of the folder will still be there, and that it will be better for waiting, because by the time they get to it, real people will have told them which parts matter.
She will get there. Most founders do, usually around the second call, usually when the later list goes up on the screen and she sees that nothing has been thrown away. Then she points at the loop and says the word the whole first version depends on.
This.
Questions founders ask about MVP scope
How many features should an MVP have?
As many as its one loop needs to work end to end, and no more. Count the steps a customer takes to get the thing they came for; each step needs to work properly. Anything outside that loop starts by hand or goes on a dated list.
Should an MVP be a web app or a native app?
For most products, a web app that works well on a phone. It reaches every user without an app store, and changes ship the same day. A native app can follow once the loop is proven; the flows and design carry over.
What can be done manually in an MVP?
Anything a founder can do by hand while the volume is low: checking documents, approving listings, sending reminders, matching the first customers. Doing it by hand first shows exactly what the automated version needs to do.
What happens to the features you cut?
They go on a next list or a dated later list, visible to everyone. Cutting is a decision about timing. Most founders find that real users reorder those lists within the first months.
Can Speed Systems help scope my MVP?
Yes. Scoping is the first step of every build we run: we map the loop with you, agree what is in version one, and fix the plan and the cost before anything is built. The first call is free, and you leave it with a clear next step.
The human founders is a Speed Systems series about the decisions founders make that no one else can make for them. The founder in this episode is a composite, drawn from several founders we have worked with or spoken to.