Your spec describes a V1, not an MVP: how to scope it right

A V1 and an MVP are not the same object

Most of the specs we receive do not describe an MVP. They describe a V1. A finished, clean, complete product, with its fine-grained settings, its polished back office and its comfort features. On paper, it reassures. In reality, it stretches the timeline by six months and pushes back the only moment that truly matters: the one where you find out whether people actually want what you are building.

The confusion is understandable. When you have never run a build, you describe what you want to own at the end, not what to build first to learn the fastest. An MVP is not a smaller V1. It is a different object, with a different goal. A V1 aims to serve a user. An MVP aims to produce proof. Confusing the two means paying the price of a finished product to answer a question that a tenth of the scope would have settled.

This article is not a plea to ship less. It is a method to reread your own spec and separate, line by line, what produces proof from what only produces comfort. The grid comes down to four proofs and one rule. You can apply it tonight to your document.

“An MVP is not the smallest thing you can build. It is the smallest thing that answers the biggest question.”

The real question: proof or comfort

Every line in a spec belongs to one of two families. Either it produces proof: it teaches you something you cannot know from your desk. Or it produces comfort: it makes the product more complete, more reassuring, more professional, without teaching you anything you did not already know. Comfort is not useless. It is just rarely urgent.

The problem is that comfort looks like progress. A back office with fifteen filters, fine-grained role management, exhaustive settings, three languages from day one: all of it fills the document and gives a feeling of progress. But none of it tells you whether your product solves a real problem for a real customer willing to pay. You are building the house before checking the land can be built on.

This figure is famous, and it should be read with caution: it comes from a study of four internal applications, not a large panel. But the order of magnitude is confirmed by any honest practitioner. Most of what we build is almost never used. Every comfort feature in your first batch therefore has a good chance of being time and money spent on something nobody will use.

MVP discipline is not about cutting at random. It is about sorting with a single criterion: what does this line teach me? If the answer is nothing, it waits for the V1. If the answer is something I can only validate on the market, it moves to the front.

This sorting pairs with a build-method choice (go fast with no-code or invest in custom) that we detailed in no-code or custom: how to choose. The two decisions reinforce each other: less scope makes custom affordable sooner.

The four-proofs grid

Here is the heart of the method. A feature earns its place in the first batch if, and only if, it produces at least one of these four proofs. Run every line of your document through the filter. The ones that produce none are not bad, they are just premature.

The four proofs, in the order the risk should fall.

An example from our own work. Gramlab was a product scoped to the strict minimum: enough to prove desire and model, not an ounce more. The result: 5000 $ collected in 15 days and an acquisition offer at 85K $. The four proofs, made fast, before building anything complete.

Note what the grid excludes: everything that produces none of these four proofs. Fine-grained settings, advanced role management, the fifteen-metric dashboard, multilingual support, the exhaustive design system. These are real V1 features. They prove nothing at the MVP stage, they reassure. Comfort waits its turn.

“Put in the first batch what makes the biggest risk fall. Everything else is an opinion about the future.”

The external-dependency rule

One rule deserves to be isolated, because it is broken almost every time. A feature that depends on a third party you do not control never goes in the first batch. An unsigned partner API, a certification body, a supply base not yet recruited, a payment integration with regulatory friction: anything that relies on someone else to exist.

The reason is simple. An external dependency turns your timeline into someone else's. You can have the best team and the best scope, but if your delivery waits on a partner's signature or a body's approval, your speed is no longer yours. You have built your critical path on a door someone else opens whenever they feel like it.

This principle has a valuable side effect: it forces you to separate what creates value from what industrializes it. Very often, the manual gesture reveals that the costly integration you wanted to build was not necessary at the start, and that a far simpler version was enough to prove the model.

Optimized scope: the question that settles it

A spec and an MVP do not optimize for the same thing, and that is the whole difference. The first optimizes for completeness: the more detailed the document, the more it looks like a finished product, the more it reassures. The second optimizes for learning: the narrower the scope, the faster you know whether the product holds. The two logics pull in opposite directions.

The stakes are not theoretical. When a product fails, it is rarely because a feature was missing. It is because there was no market for it, and that was discovered too late, after everything had been built.

A well-scoped MVP is the cheapest way to check there is a market before building everything. The question to ask of every line of your document fits in one sentence: do I need this to look complete, or to learn whether people want it? The first answer waits. The second one moves ahead.

Once market proof is made, the rest plays out on commercial execution: we laid out a concrete plan in the go-to-market plan for the first 8 weeks.

Rereading your own spec

The method comes down to a disciplined reread. Take your document, and for each feature, run it through these six questions. The ones that fail do not disappear, they join the V1. You will be surprised how small the first batch is once the sorting is done: often a third of what you had written.

This sorting commits to nothing final. A postponed feature is not an abandoned feature. It is a feature waiting to earn the right to exist, once the market has confirmed there was indeed a product to build. You are not cutting your ambition, you are ordering how it gets built.

Conclusion: a vendor optimizes scope, an entrepreneur optimizes proof

There is a deep reason why many vendors will not help you cut your spec. A wider scope means a bigger invoice. Their short-term interest is aligned with your comfort, not your learning. They will execute the document as is, because the document as is suits them.

A partner who thinks like an entrepreneur does the opposite. They remove lines. They postpone dependencies. They get you to ship the first batch as fast as possible, because their interest is your outcome, not your scope. It shows in one simple thing: are you being offered ways to add, or helped to cut?

“The best spec is not the most complete. It is the one that lets you learn fastest whether you were right.”

To go further: vendor or partner, how to choose and having your first business software built.