"MVP" now gets used to mean "the cheap version," which is not what it meant and is why so many first releases disappoint everyone. The original idea is more useful and more disciplined: the smallest thing you can build that produces a real answer to the question you are least sure about.
Minimum viable, not minimum
Viable means it genuinely works for the people using it. An MVP with one workflow that is complete and reliable is viable. One with six workflows that are all half-finished is not — it is a prototype, and users will treat it accordingly.
The reduction should be in scope, not in quality. Fewer features, done properly. Not all the features, done badly.
The question to answer first
Before deciding what to build, decide what you are unsure about. It is usually one of:
- Will people use this at all? Then build the smallest thing that puts the core action in front of real users.
- Does the process actually work this way? Then build one complete path end to end and run real cases through it.
- Can this integrate with the systems we have? Then build the integration first and the interface second, however unsatisfying that feels in a demo.
- Nothing — we know exactly what we need. Then you do not need an MVP; you need a phased build with a sensible first release.
Being clear about this determines what you cut, which is otherwise an argument about taste.
What almost always makes the first version
- One complete workflow, from start to finish, with no dead ends.
- Login and basic permissions, using an identity provider you already have.
- The data model, which is expensive to change later and cheap to get right now.
- Enough logging to understand what went wrong when something does.
What can almost always wait
- Admin screens. For the first weeks, a developer can change settings directly. Building configuration UI for five users is premature.
- Reporting and dashboards. You do not yet know which numbers matter. Export the raw data and let people use a spreadsheet for a month.
- Bulk operations. Add them when someone actually asks, which tells you what the real bulk case is.
- The second and third user type. Each one multiplies the work. Prove it with one.
- A mobile app. A responsive web page covers nearly every case at a fraction of the cost.
- Bespoke visual design. Standard components are faster, more accessible, and easier to change once you know what the screens should say.
How to run the cut
List every feature anyone has asked for. For each, ask: if this were missing on day one, would the workflow still complete? If yes, it goes to phase two. Be strict — most lists lose half their items and the product is better for it.
Then sanity-check the survivors: can a real user get from the start of the process to the end without hitting something that is not built? If not, you have cut into the workflow rather than around it, and you need to put one thing back.
The trap on the other side
An MVP that is too small teaches you nothing. If the first release does not put the core action in front of real users doing real work, you will not learn whether it works — you will just have spent money and delayed the actual question. "We will validate demand with a landing page" is fine for a new product and useless for an internal tool that three departments already need.
Size it to the question, ship it properly, then use what you learn. That is also why we scope application development in phases with a real decision point between them, rather than one large build — the same reasoning behind shipping the first useful slice early.
Have a feature list you need help cutting? That is a short and useful conversation.