In short. An MVP is not «a cheaper version of the product» — it is a way to test one hypothesis with real money in 6–8 weeks instead of a year. Building the full product straight away makes sense in exactly one case: demand is already proven by sales and the only question is capacity.
| Criterion | MVP | Full product |
|---|---|---|
| Time to first users | 6–8 weeks | From 6 months |
| Budget | From $3,000 | 3–5 times more |
| What gets tested | Whether people will pay | Nothing — you assume you know |
| Cost of being wrong | Two months lost | A year and the whole budget lost |
| Changing direction | Rewrite one flow | Rebuild half the system |
| What is inside | One flow, done properly | Every flow and every role |
| Best for | Demand not yet observed | Sales exist, capacity does not |
What an MVP really is
An MVP is the smallest product that solves one user problem completely and for real. The key word is «completely». It is not half of every feature — it is one flow taken far enough that someone will pay for it.
The classic mistake is reading MVP as «the same thing, but cheaper» and cutting every feature in half. The result is a product nobody can use, and it proves nothing: people leave not because the idea is bad but because the build is raw.
What an MVP tests — and what it does not
An MVP answers one question: will people reach for their wallet. Not «do they like it» — everyone likes everything, surveys lie. Payment, subscription or repeat use.
What it will not tell you: whether the architecture survives ten thousand users, whether acquisition pays back, and how the product behaves a year in. Those belong to the next stage, and trying to answer them upfront is the main source of bloated budgets.
When the full product is justified
There are situations where an MVP is a wasted step.
- You already sell the service manually and have hit a ceiling — the hypothesis is proven
- Regulation: in finance or healthcare a half-built version simply cannot go live
- The product replaces a working system and users will not accept fewer features than today
- Value only appears at full scale — a marketplace with three suppliers does not work
In every other case, going straight to the full product is a bet that you guessed user behaviour correctly on the first try. Usually nobody does.
What being wrong costs
The difference is not the money, it is what happens after launch. With an MVP you learn in two months that people need a different flow than the one you imagined, and you rewrite one module. With a full product you learn the same thing a year later, and half the system has to be rebuilt because the wrong assumption is baked into the data model.
We know this first-hand: TurboJobs, Converso and Polywork are our own products, and we have had to change direction at our own expense.
What to choose
If you cannot name ten people already paying to solve this problem somehow — by hand, in a spreadsheet, anywhere — start with an MVP. If those people exist and there are more of them than you can serve, build the full web service right away.
There is a middle option too: a landing page with a pre-order form and a small ad budget. Sometimes it turns out there is nothing to build yet — which is the best possible outcome.