What a nine-week MVP has to leave out

A nine-week MVP is not a small version of a big project. It is a different thing, defined mostly by what it refuses to include. Most of the value we add in the first fortnight is saying no, which is not what people expect to be paying for.

So here is the actual list — what gets cut, what never gets cut, and how to work out which side of the line something sits on.

What gets cut, almost always

The second user type

The single most expensive thing a founder can add, and the one most often smuggled in as though it were free. Each user type is its own permission model, onboarding flow, notification set and screen inventory.

If you need an admin view, the answer for nine weeks is usually a database client and one of your own team running queries. It's unglamorous and it works.

Settings, preferences and configurability

Every setting is a branch that must be built, tested, and supported forever. In an MVP the correct number of settings is close to zero — pick the sensible default and ship it. If users complain, you've learned something. If they don't, you saved a fortnight.

Anything justified by "once we scale"

Multi-tenancy, internationalisation, role hierarchies, caching layers, microservice boundaries. All real engineering, all solving problems you do not yet have, all paid for out of the runway that was supposed to get you to the point of having them.

Custom design work

A defined, clean, plain interface built on an existing component system. Not a bespoke design language, not custom illustration, not a brand refresh. Those are worth money once you know people want the product.

The integration nobody has asked for yet

"It should also sync with their calendar." Should it? Has a prospective user said so, or does it merely sound useful? Integrations are deceptively expensive — auth flows, rate limits, partial failure handling, and someone else's API changing without warning.

Native mobile apps, usually

Unless the product genuinely requires device capabilities, a responsive web application answers the question faster and for less. App store review alone can consume a meaningful fraction of nine weeks, and it's a fraction spent waiting rather than learning.

What never gets cut

This is the more important list, because these are the things that get cut by cheaper providers and they are exactly what determines whether the launch survives its first week.

How to tell which side a feature is on

Two questions settle most arguments.

First: if this is missing, does the product still answer the question we're building it to answer? If a user can complete the core loop without it, it's out — however obviously useful it is.

Second: if we add this in month four instead, what does it cost then? Most things cost roughly the same later. A few — the data model, the auth model, anything that touches every record — cost several times more. Those go in now even if they're invisible.

Cut what's cheap to add later. Keep what's expensive to change.

The conversation founders find hardest

Almost every feature on the cut list has a good reason behind it. The reasons are not wrong. A second user type genuinely would make the product better. The integration genuinely would be useful.

The point is not that these are bad ideas. It's that a nine-week timeline holds only if the scope holds, and scope only holds if someone is willing to decline good ideas. If we take everything reasonable, we are back to a nine-month build — which is the thing you came to us to avoid.

And what happens after week nine

The cut list doesn't disappear. It becomes the roadmap, in priority order, informed by what real users did with the thing you shipped. In our experience roughly half of it turns out not to matter, and something nobody anticipated turns out to matter a great deal.

That reordering is the actual return on shipping in nine weeks rather than nine months.