“MVP” might be the most abused phrase in software. To one founder it means a half-finished product; to another it means a cheap throwaway; to a third it’s an excuse to ship something broken. The original idea is sharper and more useful than any of those — and getting it right is the difference between learning fast and burning your budget.
What an MVP actually is
A minimum viable product is the smallest thing you can build to test your most important assumption with real users. The keyword is viable: it has to do one real job well enough that someone would actually use it — and ideally pay for it. It’s a learning tool with a sharp question attached: will people use this to solve this problem?
An MVP isn’t a smaller product. It’s the fastest honest test of whether the product should exist.
The two ways teams get it wrong
Mistake one: it’s not minimum
The most common failure is scope creep dressed up as an MVP. “We just need login, and billing, and a dashboard, and teams, and an admin panel, and…” — and six months later you’ve spent the whole budget before a single customer has told you whether the core idea works. If every feature feels essential, you haven’t found the core yet.
Mistake two: it’s not viable
The opposite failure is shipping something so rough it can’t answer the question. If it’s buggy, confusing, or solves the problem badly, users churn — and you learn nothing, because you tested a bad version of the idea rather than the idea itself. “Minimum” is not a license to ship broken.
How to find your real MVP
- Name the riskiest assumption. What has to be true for this to work? Build the thing that tests that.
- Pick one core workflow. The single path from “user arrives” to “user gets value.” Build that one path brilliantly.
- Write the “not now” list. Everything you’re deliberately not building yet. It’s the cheapest budget control there is.
- Define what success looks like. Decide up front what result would tell you to keep going — or stop.
The part most people miss: build it to grow
Here’s the trap. “MVP” gets used as an excuse for throwaway code — and then the idea works, demand arrives, and the team is stuck rebuilding from scratch at the worst possible moment. The smart move is to keep the scope minimal but the foundation sound: clean architecture, sensible data modelling, room to extend. A good MVP is the first version of the real product, not a prototype you have to throw away.
MVP vs prototype
A prototype is a sketch — often clickable, not functional — to test an idea or a flow before you build. An MVP is real, working software in users’ hands. Prototypes are cheap and disposable by design; an MVP is meant to live and grow. Knowing which you actually need saves a lot of money.
The bottom line
A real MVP is minimal in scope, viable in quality, and built on a foundation that can grow. Cut features ruthlessly, keep what remains genuinely good, and don’t mistake “minimum” for “throwaway.” Do that, and your first version teaches you what you need to know — and becomes the thing you scale, not the thing you scrap.
That’s exactly how we scope SaaS builds: tight on scope, serious on foundations. If you’re trying to figure out what your MVP actually is, tell us the idea and we’ll help you find the core.