Scope Creep: Why the Minimum Version Keeps Getting Bigger

What it actually looks like

You have moved the launch three times. Each time there was a specific, defensible reason, and each time you believed it. Written down in a row, the three reasons have nothing in common except their timing: all three arrived in the last fortnight before the date.

You have said "it just needs one more thing" about four different things. You remember saying it about the first one, when the product was much smaller and the sentence was probably true.

Someone mentioned a feature in passing — not a paying customer, a person on a call — and it is now in the build. Not on a list. In the build, with a branch and three days in it.

You cannot demo the product in two minutes. To show anyone the part that matters, you have to explain two other parts first, and you can feel them losing interest while you do.

The backlog grew this quarter. You shipped a great deal of work and the list is longer than it was in April, which should be arithmetically impossible and is in fact completely normal.

And the version you described to a friend nine months ago — the small one, the one you could say in a sentence — was smaller than what you are building now. It would have been out in March. You still think about that version sometimes, and you have never been able to decide whether you were naive then or braver.

Who this happens to

This is common among founders who can actually see the finished thing.

If you hold a clear picture of what the product becomes, everything short of that picture reads as a compromise you would have to explain. That vision is a genuine asset — it is what makes the product coherent, and most people building software do not have one. It is also what makes a minimum version feel less like a strategy and more like a misrepresentation of your own idea.

It is common in builders who are measuring themselves against a competitor with a funding round and a feature page. Next to that page, your version looks thin. The comparison is unfair in a way that is difficult to hold on to at nine at night: they have a team, years, and a market that has already told them what to build. You are comparing your first draft to somebody's fourth.

And it is common in teams where nobody's job is to say no. In a larger company there is a person whose entire function is to protect a release from good ideas. On a small team that person does not exist, so every good idea gets in — and they are good ideas, which is precisely the problem.

What sets it off

The most reliable trigger is a feature idea arriving mid-build, because that is when your best ideas arrive. You are deep in the product, you understand it better than you did a month ago, and you can see exactly how the new thing would fit. The clarity is real. The timing is what costs you.

A competitor's changelog sets it off. So does any side-by-side comparison, and so does a single sentence from someone you respect that begins "does it do—".

A user request sets it off, especially an early one. When you have five users, each is carrying an enormous amount of weight in your head, and a passing "it would be nice if" from one of them lands like a specification. It was not one. It was a thought they had for four seconds and have not had since.

And the launch getting close sets it off. This is the pattern worth noticing above all the others: scope grows fastest in the last two weeks. If additions were about making the product better, they would arrive evenly. They cluster at the end, because that is when the thing you are actually reacting to gets close enough to feel.

Why it keeps happening

The mechanism is that every individual yes is defensible, and the cost only exists in aggregate.

No single feature is the problem. Each one takes a few days, improves the product, and answers a real objection you can name. There is no moment where you make an obviously wrong decision — which means there is no moment where a reasonable person would stop you, including you. Meanwhile the total is doing all the damage, and nobody experiences a total. You experience Tuesday.

Work also expands to fill whatever room is available. Scope has no natural stopping point, so if the only limit is your runway, the scope will find your runway and settle exactly there. The date does not slip because you were slow. It slips because nothing in the system was holding it.

Then there is the part that is genuinely difficult to say to yourself: adding features is real work. It is hard, it is skilled, it produces visible output, and it is therefore the most effective form of avoidance available to a builder. Nothing about it looks like flinching. You can do it for four months and produce a commit history that any engineer would respect.

What it is avoiding is the moment of measurement. While you are still building, the product is potentially excellent — the reception is imagined, and imagined receptions are wonderful. The moment you ship, potential collapses into a number: how many signed up, how many stayed, what they actually said. Every extra feature buys another week in the world where the answer is still unknown, and it buys it with the one thing you cannot replace.

And there is a factual error underneath the whole pattern. You do not know which of these features matter. You cannot know, because the information is held by users who have not used it yet. Building more before launch is an attempt to buy that information from a shop that does not stock it.

What actually helps

Write the cut line, in one sitting, today. List every feature currently in the build. Then mark the three without which the product is pointless — not weaker, pointless, as in the core promise does not happen. Three is not a magic number; it is a number small enough to force the question. Everything unmarked goes into one file called v2, and the act of writing them there is the thing that makes cutting them survivable.

Keep a parking lot and put the mid-build ideas in it immediately. Not a backlog with priorities and estimates — a plain document. Write the idea in full while it is fresh, then close the file and go back to what you were doing. Most of what the idea wanted was to be recorded before it evaporated. You can tell which ones were real when you re-read the list a month later and half of them have gone flat.

Fix the date and let the scope move, instead of the other way round. Pick a ship date you say out loud to someone who will remember. Then treat it as the constant. When something has to give, it is the feature list — and because the date is fixed, that decision gets made deliberately in daylight rather than by default at midnight.

Turn requests into counts before they turn into branches. One line per request, one tally mark each time someone asks unprompted. A feature three people asked for is signal. A feature one person mentioned once is a conversation you had. The tally costs nothing and quietly removes most of the pressure you are currently feeling from a sample size of one.

Then ship the sharp version, on purpose. A tool that does one thing unmistakably well is easier to explain, easier to recommend, and easier to be honest about than a product that does six things adequately. The features you cut are not lost. They are waiting behind the only thing that can tell you which of them deserve to exist, which is a real user in a real week — and you cannot get one of those without shipping something first.