What an MVP actually is, and what it isn't

Almost every first conversation I have includes the words "let's start with an MVP". Then the feature list arrives and it is a complete product with the polish removed. Those are different things, and confusing them is the single most expensive mistake I see.

An MVP is an experiment, not a discount

A minimum viable product exists to answer a question you cannot answer by thinking harder. Will people book through a link instead of calling? Will drivers actually use the app? Will anyone pay for this? The MVP is the cheapest honest way to find out.

That reframes the whole scoping conversation. The question stops being "what can we afford to build?" and becomes "what is the least we can build that would change our mind?" Those produce very different feature lists.

Cheap versions of everything is the failure mode

The tempting move is to keep all fifteen features and build each one to 40%. It feels fair — everybody's favourite thing survives. It is also the reliable way to produce something nobody wants to use, which teaches you nothing except that the thing was bad, when in fact only the execution was.

Two features that work properly beat fifteen that half work. If a feature is in, it should be good enough that its failure means something.

How to actually cut the list

Go through the features and ask one question of each: if this were missing on day one, would a real user walk away? Not "would they complain" — complaints are fine, and are useful data. Would they stop using it.

• Login with email, phone, Google and Apple — pick one. You can add the rest in an afternoon once people are actually signing up.
• An admin panel to edit everything — start with the three things that change weekly. The rest can be a database change for now.
• Notifications on every event — pick the one that brings someone back to the product.
• Analytics dashboards — you have almost no data yet. A spreadsheet export is enough for months.

The part people skip

An MVP is only worth building if you have decided, in advance, what you will do with the answer. Before I start, I ask what number would count as working and what would count as failed. If there is no answer, we are not building an experiment — we are just building a small product, and we should be honest about that instead.

The point of shipping early is not to save money. It is to stop spending money on the wrong thing sooner.

What this looks like in practice

The booking system in our examples runs about four weeks. It has a calendar, a public booking link, reminders and optional deposits. It does not have inventory, payroll, a loyalty scheme or a customer app. Not because those are bad ideas — because after four weeks the owner knows whether customers will book online at all, and every one of those features would be designed better with that answer in hand.

If it works, you build the next thing knowing something. If it does not, you found out for the price of a month rather than the price of a year.