How to Scope an MVP: What to Build, What to Fake, What to Cut

Your feature list has 23 items on it and every one of them feels load bearing. That is the normal starting position, and it is exactly why most first versions take five months instead of five weeks. Learning how to scope an MVP is not a project management skill. It is the difference between finding out whether anyone wants this in March and finding out in August, having spent the intervening five months building settings pages for users who do not exist.

Scope creep does not feel like scope creep from the inside. It feels like being thorough. Every feature you add has a reason, the reason is usually sensible, and the cumulative effect of forty sensible reasons is a product that never ships. Nobody adds three months to a build on purpose. They add two days, forty times, each one justified.

The founders who get to a real answer quickly are not writing better code. They are making a harder decision, earlier, about what the first version is not going to do.

An MVP is a question with a deadline, not a small product

The word minimum has done real damage. It gets read as "cheap version of the finished thing", so founders build a worse copy of what they imagine in two years, badly, across four months. That is not an MVP. That is a slow prototype with a marketing name.

An MVP is an experiment. It exists to answer one question you cannot answer by thinking, and the only features that belong in it are the ones required to get that answer. Everything else, however sensible, is a bet placed before the odds are known.

So before you write a line of code, write the question down. Not "will people like it". Something you can be wrong about:

Will 20 freelance bookkeepers, given a way to turn a bank CSV into a client-ready summary, do it twice in their first fortnight and 5 of them pay 19 a month for it?

Now the feature list has a judge. Every item either helps you answer that or it does not, and most of them do not. If you cannot write your question this specifically, the problem is not scope, it is that you skipped validating the idea before building and you are hoping the build will do it for you. It will not, it will just cost more.

How to scope an MVP: pick the one job

Your product will eventually do many things. The first version is allowed to do exactly one, end to end, with no dead ends in the middle.

Find it by asking what the user was doing in the ninety seconds before they needed you, and what they need to be holding when they are done. That path, entrance to result, is the one job. Everything to the side of it is a feature for a version you have not earned yet.

A useful sanity check: describe your MVP in a single sentence with one verb in it. "It turns a bank CSV into a client summary." If your sentence needs an "and", you have two products and you are about to build both at half quality. Pick the half that makes someone say "oh, that is useful" and cut the other one for now. The answers page on whether to build an MVP or a landing page first is worth reading before you commit to building anything at all, because sometimes the honest scope is a page and a payment link.

Build one, fake two, cut the rest

Once the one job is chosen, take your full feature list and put every item into one of three columns. Not two. The middle column is where the time savings live, and it is the one founders skip.

Build it is smaller than you think. The one job, a way in, a way to pay, one way to reach you, and one event you can count so you know whether it worked. That is five things and a normal person can build them in a fortnight.

Fake it is the column that separates people who ship from people who plan. Onboarding is a call. The dashboard is a spreadsheet you email on Fridays. The integration is a CSV in and a CSV out. The clever automated feature is you, at your desk, typing the answer. This is not cheating, it is the oldest advice in startups: Paul Graham's Do Things That Don't Scale is fundamentally an argument that manual effort early buys you information that automation would have hidden. You learn more in ten manual onboardings than in the four weeks you would have spent automating them, and you learn it before the code is written.

Cut it is everything you are keeping for a hypothetical. Settings pages for users with no preferences. Teams and permissions when you do not have a single team. The second use case, before the first one has anyone in it. Anything already solved by a library or a service you can pay 20 a month for, because a hand-rolled auth system has never once been the reason a startup won.

If a feature genuinely cannot be faked and its absence would not stop the experiment, it is not in the middle column. It is in the third one.

Four questions that kill a feature

Run every survivor of the build column through these. Each one has killed more work than any planning document.

1. If I removed this, would the experiment still produce an answer? If yes, remove it. This is the whole method compressed into a sentence.
2. Who exactly asked for this? A name, a real conversation, a date. "Users will expect it" means nobody asked. If you have no names, you have a preference, not a requirement.
3. Can a human do it for the first twenty people? If yes, that human is you, for now. Move it to the fake column and get the fortnight back.
4. What breaks if I ship without it? Say it out loud. If the answer is "it feels unfinished", that is a feeling, not a breakage, and it is the most expensive feeling in software.

The features that survive all four are your MVP. Usually there are three or four of them, and founders are consistently shocked by how short the list gets. That shock is the point. Everything you cut was time you were about to spend before you knew anything.

Set the timebox before you set the scope

Most founders write the feature list, then estimate. That is backwards, because a list always expands to fill whatever estimate it is given.

Do it the other way round. Decide the deadline first, then ask what can be true by then. Four to six weeks of real calendar time is the right order of magnitude for a first version, and if you are building around a job, halve everything to fit the hours you actually have. Then hold the date and let the scope move, rather than holding the scope and letting the date move, which is the polite way every side project quietly dies.

Write it down in one line, with a number, a date, and a consequence:

By 15 September I will have shipped the CSV to summary flow to 20 bookkeepers. If fewer than 5 use it twice, I stop building features and go back to interviews.

That sentence does two jobs. It stops the scope drifting, and it means the launch produces a verdict instead of a vibe. Without it you will ship, get a lukewarm week, and add features to explain it away, which is how a four week build becomes a nine month one. If you are the kind of founder who negotiates with your own deadlines, the fix is not more discipline, it is external accountability that will not renegotiate on your behalf.

The features founders defend hardest

There is a shortlist of things almost everyone fights to keep, and almost nobody needs on day one. Recognise the argument you are about to make:

• "It looks unprofessional without it." Twenty early users forgive rough. They do not forgive useless. Ugly and working beats polished and pointless every time.
• "It will be harder to add later." Occasionally true for data model decisions, almost never true for features. And "harder later" is a cost you only pay if the thing succeeds, which is the good problem.
• "The competitor has it." The competitor has 400 customers and eleven engineers. You are not playing the same game, and matching their feature list is how you arrive third at their market with none of their distribution.
• "I have already started it." Sunk cost, wearing a hoodie. The half-built feature is gone either way, and finishing it does not get the hours back.
• "It is the interesting part." This is the honest one, and it is the most dangerous. The interesting part is often the part nobody is paying for. Building it feels like progress and grades out as fake work.

How to tell your scope is right

You have scoped it correctly when all of these are true:

• You can describe the whole thing in one sentence with one verb.
• The build is under six weeks, and you have not quietly assumed a perfect week.
• A named person, someone you have actually spoken to, is waiting for it.
• You can name the number that will tell you it worked, and the number that will tell you it failed.
• At least three things on your list moved to "a human does that for now".
• Removing any remaining feature would genuinely stop you getting an answer.

If you cannot honestly tick these, the scope is still too big, and the shortfall is almost always in the fake column. When you are close, how to know your MVP is ready to launch covers the last mile, and how to get your first 100 users covers what happens the day after, which is the part most people have not planned at all.

The bottom line

How to scope an MVP comes down to one decision made honestly: what question are you paying to answer, and what is the shortest thing that answers it. One job built properly, two or three things faked by hand, and everything else deleted from the list without ceremony.

The measure of a good MVP is not how much it does. It is how fast it tells you the truth. A four week version that returns a clear no is worth more than a six month version that returns a maybe, because the first one leaves you five months to go and be wrong about something else, faster.

If your scope keeps growing every time you look at it, that is not a discipline problem you can think your way out of. It is a missing referee. GRILLR takes the idea, cuts it to the one job, puts a date on it, and refuses to accept a longer list next week because you thought of something clever on Sunday. Deciding how to scope an MVP is easy in the abstract. It is holding the scope in week three, when the new idea is genuinely good, that decides whether you ever ship.