"Minimum viable" is one of the most misread phrases in software. Teams hear minimum and ship something flimsy, or hear viable and ship everything. The useful version sits in between: the smallest thing that delivers real value and does not have to be rebuilt the moment it works.
Start from the one outcome that matters
Before features, agree on the single outcome the MVP must prove. Not "a booking system" — but "a patient can book and receive a confirmation without calling us." Everything that does not serve that outcome is a candidate to cut.
Cut scope, not quality
The mistake is trimming an MVP by lowering engineering standards — skipping validation, auth or data modelling to "move fast." That debt comes due exactly when the product succeeds. Instead:
- Cut features, keep foundations.
- Ship one workflow end to end, done properly.
- Design the data model for where you are going, even if the UI only covers today.
Build the seams you know you will need
You do not have to build multi-tenancy, roles or integrations on day one — but you should leave clean seams where they will attach. A little architecture foresight is cheap now and priceless at version two.
Decide what "done" proves
An MVP is an experiment. Define, up front, what result would tell you to invest further and what would tell you to change direction. Otherwise you have built a demo, not a decision.
A good MVP is small in scope and serious in engineering. That combination is what lets it grow into the real thing instead of blocking it.
This is the discovery work we do before a single screen is built. Talk to us about your product.
- #mvp
- #product-strategy
- #discovery
- #scope
