The most expensive mistake in custom development is not bad code — it is building features nobody uses. An MVP exists precisely for this: so you spend ten percent of the budget validating whether the other ninety is worth spending at all. The key is deciding what goes in — and above all, what does not.
What an MVP actually means
An MVP is not a “stripped-down app” or a prototype to show off. It is the smallest production system that can carry one key process end to end for a real user. The word production matters: an MVP runs for real, with real data, not in a demo. Otherwise you validate nothing but the design.
What belongs in an MVP
One main process from A to Z — for example receiving an order, processing it and shipping it. Plus the essential authentication, basic roles, one critical integration (payments or your main system) and measurement, so you can see whether people actually use it. The goal is that the first real user can complete the whole task without anyone rescuing them by e-mail.
What never belongs in an MVP
A second and third role “just in case”, exports to five formats, configurability of everything, an admin for managing things that do not exist yet, and integrations to systems you may never connect. Each of these sounds reasonable and each pushes launch back by weeks. The rule is simple: if the first user does not need it to finish the main process, it goes into phase two.
Why exactly 90 days
Three months is long enough to produce a real production system, and short enough that the company does not lose momentum and budget before it sees a result. With a demo every Friday you get twelve points to correct course — so on launch day you do not get a surprise, but a product you watched grow. What does not get validated in the first ninety days usually will not be validated in nine months either; you just find out at greater cost.
Discipline about MVP scope is not about doing less. It is about doing the right things sooner — and keeping a validated base on which phase two is built fast and safely.