What belongs in an MVP — and what doesn't

An MVP is an experiment, not a small product

The phrase "minimum viable product" gets read as "the cheap version of what we are actually building." It is not. An MVP is an instrument for answering one question: will anyone use this? Every hour spent on something that does not help answer that question is an hour spent on a guess.

This reframing has a practical consequence. Before scoping anything, write down the question and the number that answers it. "Will freelancers track expenses in this if it takes under a minute?" — measured by the share of signups who log a second expense within a week. Now every proposed feature has a test to pass: does it move that number, or does it just make the product feel more finished?

What ships in the first release

One core loop, complete

Pick the single journey the entire idea rests on and build it properly, start to finish. A user who cannot complete that loop learns nothing and teaches you nothing. Half-finished journeys produce feedback about the half that is missing, which you already knew.

The minimum authentication you need

Enough to tell one user from another and let them come back. Email links or a single social provider usually covers it. Password resets, SSO, and account management can wait until someone asks.

Analytics — non-negotiable

This is the one thing we never cut. An MVP without instrumentation is not an experiment, it is a launch you cannot learn from. You need to see where people drop out of the core loop and how many come back. Everything else in the release exists to generate that data.

A real production deployment

Not a staging link shared with twelve friends. Real users behave differently from people doing you a favour, and production surfaces problems — latency, error handling, the state of your data model — that a demo never will.

Somewhere for feedback to land

A support address, an in-app form, a shared inbox. Something cheap. Most of what you learn in the first month arrives as sentences, not as numbers.

What waits — and why

Billing and subscriptions

Payment infrastructure is deceptively expensive: plans, trials, proration, refunds, failed charges, tax, and the support burden behind all of it. Until you know people want the product, that work is speculative. (There is one important exception — see below.)

Roles, permissions, and teams

Your first users do not have an org chart inside your product. Permission models are architecturally invasive and difficult to guess at correctly before you have seen how teams actually use the thing.

Admin panels

At ten customers, a database client and a few scripts are faster than the admin panel you would build, and cost nothing. Build the panel when a non-engineer needs it daily.

A second platform

Shipping iOS and Android and web simultaneously multiplies the work and divides the learning. Pick where your users already are, win there, then expand with evidence.

Optimisation for load you do not have

Caching layers, sharding, queue infrastructure, and multi-region deployments are real engineering costs paid against imaginary traffic. Build for the scale you have plus one order of magnitude, and no further.

The exception: when the hypothesis is about money

Everything above assumes your open question is whether people will use the product. Sometimes it is not. For a consumer subscription app or a paid-from-day-one SaaS tool, the question is whether people will pay — and a launch without a paywall answers nothing at all.

In that case the paywall is the experiment. It ships in the first release, and the metric you watch is trial-to-paid conversion rather than repeat usage. The principle has not changed; only the question has. Work out which question you are actually asking before you scope anything.

Cut features, never foundations

There is a version of this advice that gets startups into trouble: build it fast and throw it away later. In practice, "later" arrives the week you get traction, which is the worst possible week to rewrite anything.

The distinction we hold to is between features and foundations. Features are what the product does — cut them ruthlessly. Foundations are the data model, the deployment pipeline, and the boundaries between components. Those cost little to get right at the start and a great deal to fix once real users depend on them.

The uncomfortable part

Scoping an MVP means writing a list of things you believe in and then deleting most of it. Founders find this genuinely difficult, and they should — the deleted items are usually good ideas. They are just good ideas that are not being tested yet.

If you want a second opinion on where the line should sit for your product, get in touch. Arguing about scope is the part of this job we enjoy most.