MVP (minimum viable product)

The idea behind it

The term predates lean startup but was popularised by it, and the underlying logic is about reducing the cost of being wrong. Every product rests on assumptions: that a particular group has this problem, that they will change tools to solve it, that they will pay. Most of those assumptions are untestable by discussion. An MVP is the cheapest instrument that makes one of them testable.

That framing implies a discipline that is easy to skip: decide what result would make you stop or change direction before you build. Without that, whatever happens gets read as encouraging, and the exercise measures nothing.

What "minimum" actually means

Minimum applies to scope, not to quality. One workflow, done properly, beats six half-working ones — a broken experience produces data about your execution rather than about your idea. What legitimately gets cut is breadth: features, edge cases, settings, admin panels, integrations, and often automation. Doing the work by hand behind a simple interface is a perfectly respectable MVP, and it teaches you the process before you encode it.

Some things are not optional even at this stage. If you handle personal data, GDPR applies to the prototype as much as to the product; "it is only an MVP" is not a legal category.

What to watch out for

An MVP is an experiment, not a cheap version of the plan. Two failure modes follow from ignoring that:

1. The MVP that is just a small product. Built to be launched rather than to answer a question, with no hypothesis and no stated threshold. It ships, gets a shrug, and nobody can say what was learned.
2. The MVP that becomes the architecture. It works, so it stays, and five years of features get built on scaffolding meant to be discarded. Prototype code is written to be thrown away — decide consciously whether you are keeping it.

This is where generated apps have genuinely changed the economics. An AI app builder can produce a testable interface in an afternoon, which lowers the cost of the experiment enough to run several. But it also lowers the cost of skipping the thinking, and a fast prototype with no hypothesis is still measuring nothing. See vibe coding for the discipline that keeps the prototype from quietly becoming production.