"MVP" is one of the most abused acronyms in tech. Founders use it to mean "cheap version," investors use it to mean "proof it works," and agencies use it to mean "the small project we'll upsell you on later." So let's be precise, because the definition you hold in your head determines how you spend your first $50,000.
An MVP — minimum viable product — is the smallest version of your product that delivers real value to a real user and lets you learn whether people actually want it. That's it. Every word in that sentence is load-bearing, and most failed MVPs failed because the founder ignored one of them.
What an MVP is — word by word
- Minimum — the least you can build. Not "the least we could be proud of." The actual least. If it feels slightly embarrassing, you're probably close.
- Viable — it has to actually work and actually help. A broken thing isn't an MVP, it's a broken thing. Viable is the word people skip, and it's why "MVP" became a synonym for "junk."
- Product — real software a real person uses to get a real outcome. Not a deck. Not a Figma file. Something live, on a domain, that does the job.
The tension between "minimum" and "viable" is the whole game. Too minimum and it doesn't work, so you learn nothing. Too viable and you've spent six months building features for users who don't exist yet. The art is finding the narrowest slice that's still genuinely useful.
An MVP is not a cheap product. It's a narrow one. You're not lowering quality — you're shrinking scope.
What an MVP is NOT
Most of the confusion comes from mixing the MVP up with three other things:
| Not this | Because |
|---|---|
| A prototype | A prototype demonstrates an idea — clickable mockups, no real backend. An MVP is real, working software people can actually use. |
| A cheap product | "Cheap" lowers quality. "Minimum" shrinks scope. An MVP can be beautifully built — it just does one thing. |
| Version 1.0 | 1.0 is what you ship when you already know what users want. An MVP is how you find out. |
Why the MVP exists at all
The MVP isn't a budgeting trick — it's a learning instrument. The single most expensive mistake in software is building the wrong thing well. You can write flawless code, ship it on time, and still fail completely because nobody wanted it. The MVP is how you de-risk that before you've spent the whole budget.
Every product idea is really a stack of assumptions: people have this problem, they'll use software to solve it, they'll trust us with it, they'll pay for it. The MVP picks the riskiest assumption and tests it with real users as fast as possible. Everything not in service of that test is, by definition, premature.
How to scope an MVP (the part founders get wrong)
Here's the method I use with founders, and it takes about an hour in a room:
- Write the one sentence. "This product helps [who] do [what] so they can [outcome]." If you need two sentences, your scope is already too big.
- Find the single core flow. The one path a user takes to get the main outcome. For a marketplace it's "list one item → someone buys it." Everything else is support scaffolding.
- Cut everything that isn't that flow. Settings pages, profile editing, notifications, dark mode — all of it waits. Be ruthless. It feels wrong; do it anyway.
- Build it end-to-end, deployed, for real users. Not a demo. Real people, real data, real money if money's involved.
- Watch what they actually do. Their behaviour, not your roadmap, decides what's next.
If you want the cost side of this, I broke down how much it costs to build an app in detail — the short version is that a focused MVP lands in the $30k–$80k range, and scope is the dial that moves it.
What's changed in 2026: faster and cheaper
The MVP playbook is the same, but the economics have shifted hard in the founder's favour. AI-assisted development has eaten most of the boilerplate — auth flows, CRUD endpoints, test scaffolding, the repetitive 60% of any build. That work used to be where weeks and dollars went.
In practice, the MVP timelines that were three to four months a couple of years ago are now routinely six to eight weeks for the same scope. The savings don't come from cutting corners — they come from senior engineers spending their time on the decisions and the hard 40%, while the machine handles the typing. The result: you can test your riskiest assumption sooner, and for less, than at any point before.
The trap is thinking "cheaper to build" means "build more." It doesn't. The discipline of staying minimum matters more than ever — because now the temptation to add "just one more feature, it's so quick now" is stronger too.
The closing test
Here's the question that cuts through every MVP debate: what's the one thing this product must do for a user to get value, and what's the fastest way to put that in their hands? If you can answer that in a sentence, you have your MVP. If you can't, you don't have a scoping problem — you have a clarity problem, and no amount of engineering will fix it.
Build the smallest real thing. Get it in front of real people. Let them tell you what to build next. That's the whole discipline, and it's never been cheaper to run the experiment.
Scoping your MVP?
We start every build with a paid two-week scoping sprint — a real spec, an architecture, and a fixed price for the MVP itself. Same senior team, end-to-end. Tell us the one sentence.
Start a project →