The most expensive mistake in software isn't building the wrong thing — it's building the right thing too late to matter. An MVP is a tool for buying information cheaply: you spend a fraction of the full build cost to learn whether the product is worth building at all.
What an MVP actually is
An MVP is not a stripped-down version of your final product. It's the smallest thing you can build that tests the one assumption most likely to kill the project. If you're not sure people will pay, the MVP tests willingness to pay. If you're not sure the workflow works, the MVP tests the workflow. Everything else waits.
Name the riskiest assumption
Before scoping an MVP, write down the single assumption that, if wrong, makes the whole product fail. Common ones: will users adopt this, will they pay for it, will the workflow produce better results than the manual version. The MVP exists to test that one assumption — not to deliver a feature list.
- Adoption risk: will the target user actually use this?
- Value risk: will they pay, or switch from what they use today?
- Feasibility risk: can the workflow produce reliable results at acceptable cost?
Scope to the assumption, not the feature list
Once the assumption is named, the MVP scope becomes clear: include everything that tests it, exclude everything that doesn't. A login screen is needed to test adoption. A settings page is not. A single working workflow is needed to test value. A polished design system is not. This is why MVPs feel uncomfortable to build — you're deliberately leaving out things that feel essential.
What to leave out of version one
A common trap is to include features because stakeholders expect them. Every feature added to the MVP adds build time and dilutes the signal — you learn less about the core assumption because you're also maintaining peripheral features. Cut ruthlessly, and keep a written list of what was deferred so it's a decision, not an oversight.
- Admin tools: manage data directly until the volume justifies a UI.
- Notifications: start with email, build in-app later.
- Integrations: connect the one system that matters, not all of them.
- Polish: functional beats beautiful when you're testing whether to build at all.
When to move from MVP to full build
The MVP answers a question. If the answer is yes — the assumption holds, the metric moves, users return — the full build is justified and scoped with real data. If the answer is no, you've spent weeks instead of months, and you know exactly why. Either outcome is a win; the only failure is building a full product on an untested assumption.