What is an MVP (minimum viable product)?

What the term actually means

The phrase comes from lean startup practice, where the point of a first release is learning rather than revenue. "Minimum" refers to the amount you build, "viable" refers to whether it genuinely works for the person using it, and the product only qualifies if both hold at once. Drop the first and you have built version one; drop the second and you have shipped something nobody can use.

The useful reframing: an MVP is an experiment with a user interface. It exists to answer a question you have written down — will this audience do this task in this way, often enough to matter — and every scoping decision follows from whether it moves that answer closer.

What an MVP is not

It is not a discount version of the full product. Cutting quality rather than scope produces something people bounce off for reasons that have nothing to do with your hypothesis, and then you have paid for an experiment that returns noise. The correct cut is fewer things, done properly — never everything, done badly.

It is also not a permanent excuse. "It's just the MVP" stops being true the day a customer depends on it, and plenty of companies are still running one three years later because nobody defined what success would trigger. Decide up front what result means build it properly, and what result means stop.

How small is 'minimum'?

One workflow, end to end, for one clearly named user. That is the unit — not one screen, and not one feature from each of five areas. A person should be able to start the task, finish it, and get the thing they came for, without hitting a dead end where you meant to build the next part. Everything outside that single path is a candidate for being cut, including work that feels obviously necessary.

Most of what gets cut is administrative: settings screens, user management, bulk actions, reporting, and the second and third user role. Much of it can be done by hand at first — a spreadsheet behind the curtain, an onboarding you run personally, a report you assemble once a week. Manual work at low volume is not technical debt, it is a deliberately cheap way to avoid building the wrong automation.

What makes it 'viable'?

Viable means someone can rely on it for the task it covers. In practice that is a short, non-negotiable list — the one workflow completes, the data is stored properly and backed up, access is controlled if the data is personal, failures are visible to you, and it works on the device people will actually open it on. Below that bar you are not measuring demand, you are measuring tolerance.

Because that list is where most MVP arguments actually happen, it has its own piece: what an MVP needs to be viable — what stays in the first release and what can safely wait.

The failure nobody names

Shipping an MVP with no way to learn from it. If nothing records who used it, how far they got, and where they stopped, then a quiet launch and a promising launch look identical, and the next decision gets made on opinion — which is exactly what the exercise was supposed to replace. The instrumentation does not need to be elaborate; it needs to exist before launch, and it needs to answer the question you wrote down.

Write the hypothesis as a sentence, decide what number would confirm it, and make sure the release can produce that number. If it cannot, you are building version one and calling it an MVP.

How I scope one

By mapping the workflow as it actually runs — every step, every exception, every workaround someone invented — and then cutting to the shortest path that still delivers the outcome. That map is also what makes the number honest, because scope is what moves the price of a custom web app more than anything else.

Sometimes the honest recommendation is not to build at all — that an off-the-shelf product covers it, or that the workflow needs fixing before software is pointed at it. Some proposals deserve a no before they cost you a quarter, and saying so early is part of how I take on app work.

Questions