Many teams set out to build an MVP and actually ship a full first version, slower to release and costlier to fix. A minimum viable product is not a small v1: it is the shortest path to test a hypothesis. Here is how to frame the right scope, what you keep and what you cut. The difference lies less in the size of the product than in the intent behind each choice.
The bloated MVP trap
The word minimum fades fast. Every stakeholder adds ‘just one thing’, and the scope swells until it looks like the final product. The result: months of development before the slightest user feedback, a budget spent on assumptions, and a team that learns too late that the starting hypothesis was wrong. An MVP application that holds everything no longer tests anything. The larger the scope, the more the signal dilutes: you cannot tell which feature convinced, or drove people away. The useful question is not ‘what can we build’, but ‘what do we need to learn’.
Building an MVP under these conditions costs the price of a finished product for the value of an unverified bet.
Start with the hypothesis, not the feature
Before writing a line of code, state the hypothesis to validate in one testable sentence: who, which problem, which expected behaviour. ‘Freelancers will track their budget every week if the app does it for them.’ A clear hypothesis dictates the scope: only the features that help prove or disprove it deserve to exist in the first cut.
In the WiseBudget case study, the hypothesis fit in one sentence and let us cut half of the screens imagined at the start. To scope an MVP is, first of all, to give yourself a sorting rule.
What you keep, what you cut
Once the hypothesis is set, every idea goes through a simple filter. Keep what touches the critical path; defer the rest.
- Keep: the path that triggers the behaviour you measure, from entry to a result the user can actually see.
- Cut: settings, multiple roles, dashboards and edge cases that only exist for ‘later’.
- Simplify: payment, notifications or export can stay manual or faked until the hypothesis holds.
- Instrument: without measurement, an MVP proves nothing; decide from the start what to observe.
This sorting is not final. Whatever you cut joins an explicit waiting list; if the hypothesis is confirmed, those items come back, prioritised by what you have learned.
An MVP is not a disguised v1
The most common drift is to treat the minimum viable product as a smaller version 1.0. An MVP is allowed to be ugly, partly manual and disposable. A v1 has to last. Confusing the two means paying the price of robustness before you have proof that a user wants it.
A useful warning sign: if you are talking about technical debt, scaling or a design system before you have ten users, you are building a v1, not an MVP. Those topics are real, but they come after the proof, not before.
A successful MVP can be a commercial failure: it cost little and proved the hypothesis wrong. That is good news, not waste.
Our method to scope an MVP
We scope every MVP in three steps. First, write the hypothesis and its measurable success criterion: a rate, a delay, a number of repeated uses. Then, list the possible journeys and keep only the critical one, the path that triggers the measured behaviour. Finally, set a short release date, a few weeks, that forces the trade-offs. Scope follows the deadline, not the other way around: with a fixed date, cutting becomes a decision rather than a frustration. This is the heart of our product engineering: shipping fast an object that answers a question, not a catalogue of features.
Preparing an MVP application and still unsure about scope? The right reflex is to start with the hypothesis, not with the list of screens. Tell us in one sentence what you are trying to prove, and let’s scope it together.