What is an MVP?
An MVP, or minimum viable product, is the smallest version of a product that a real user can actually use to get real value, built to answer one specific question: does the core assumption behind this business hold up when tested against actual behaviour rather than opinions gathered in a meeting room. The term comes from Eric Ries and the Lean Startup methodology, published in 2011, though the practice of shipping a narrow first version to learn fast existed long before it had a name.
The confusion worth clearing up first is what an MVP is not. It is not a prototype, which can be a static mockup that nobody actually uses. It is not a beta, which is usually a near-finished product released for final bug testing before a full launch. An MVP is a working product, live and usable, deliberately narrow, built to be used by real people rather than admired by stakeholders.
The word minimum causes the most confusion in practice. It does not mean cheap, unpolished or half-broken, it means scoped to the smallest set of features that still lets a real user complete the task the assumption depends on. A minimum viable product that fails at the viable half of its name, because it crashes, confuses users or does not actually solve the problem, produces evidence that is worthless, since nobody can tell whether the idea failed or the execution did.
Why an MVP matters
Three reasons explain why this approach beats building the full product first.
- It tests the riskiest assumption before spending the full budget. Every product idea rests on at least one belief that could be wrong, that people want this, that they will pay for it, that they will use it the way it was imagined. An MVP is built to test that specific belief cheaply, before the budget for a complete build is committed to something nobody wants.
- It replaces internal opinion with real user behaviour. A room full of stakeholders can debate a feature for weeks without resolving anything. A handful of real users interacting with a working version settles the same question with actual evidence in days.
- It shortens the time before real revenue or real validation. A narrow but working product can start generating income, feedback, or investor confidence months before a fully-featured version would have shipped, which matters directly for cash flow and for fundraising timing.
The trade-off to be honest about: an MVP is a research tool wearing the shape of a product, not a shortcut to the final product. Some of what gets built will be discarded once the assumption is tested, and that is the intended outcome, not a failure of planning.
How it works
Four principles define a well-built MVP, regardless of industry.
One core assumption, clearly named. Not a list of assumptions, one specific belief the team most needs validated, since trying to test everything at once produces evidence about nothing. Writing that assumption down as a single sentence, and forcing every scope decision to be checked against it, is what keeps a team from quietly rebuilding the full product idea under an MVP label.
Real usage, not a demo. The MVP has to be used by actual target users doing the actual task, not shown in a sales meeting, because behaviour under real conditions is the only signal worth trusting.
Deliberately incomplete, not badly built. Scope is cut aggressively, but what remains has to work reliably. A broken narrow product produces noisy, misleading evidence, which is worse than no evidence at all.
A defined success metric decided before launch. What result confirms the assumption, and what result kills it, agreed before the MVP goes live, not interpreted generously afterward to match whatever happened. This is the step teams skip most often, and the one that turns an MVP into a real test rather than a vanity launch.
Implementation
The order below front-loads the decisions that determine whether the MVP actually tests anything.
- Name the single riskiest assumption first. Write it as a testable statement, not a vague hope, since a vague assumption produces a vague result that convinces nobody either way. A useful test is whether a competitor or an investor could disprove the statement with a single data point, if they could not, it is probably still an opinion rather than a testable claim.
- Cut scope until only what tests that assumption remains. Every feature that does not directly help answer the core question is a candidate for removal, no matter how reasonable it seems in isolation.
- Decide the pass and fail thresholds before building. A specific number, a specific behaviour, a specific rate, defined in advance so the result cannot be reinterpreted after the fact to protect the idea.
- Build only what real usage requires to function. Manual processes standing in for automation are acceptable behind the scenes as long as the user-facing experience genuinely works, a technique often called doing things that do not scale.
- Recruit real target users, not friendly insiders. Feedback from people who already want the founder to succeed is close to worthless as a signal, since it rarely reflects how a stranger would actually behave. Recruiting even a small number of genuine strangers, through a paid ad, a relevant community or a cold outreach list, produces far more honest evidence than a much larger group of people already rooting for the project to succeed.
- Set a fixed timeframe to gather the result and decide. An MVP that runs indefinitely without a decision point stops being a test and quietly becomes the permanent product by default, carrying all its deliberate shortcuts with it.
What it costs
A focused MVP covering a single core workflow, built by a professional development team rather than assembled through no-code tools alone, typically costs between roughly 15,000 and 60,000 euros, depending on the complexity of the workflow and how many integrations it needs to real systems like payments or existing business software. A no-code or low-code version of the same narrow scope can start considerably lower, often a few thousand euros, when the core assumption can be tested without custom backend work.
The mistake that inflates this budget the most is not technical complexity, it is scope creep disguised as thoroughness, adding features because they seem obviously necessary rather than because they are required to test the one assumption at stake. An MVP that grows to cover every eventuality before launch has quietly become a full product with an MVP label attached, and it costs and takes as long as one.
A separate cost worth budgeting for honestly is what happens after the test, whichever way it goes. If the assumption holds, the shortcuts taken to move fast, manual workarounds, limited error handling, minimal design, usually need real engineering investment before the product can scale past its first users. Treating that follow-on cost as a known step rather than a surprise makes the MVP phase easier to defend to an investor or a founder counting every euro.
Conclusion
An MVP is a deliberately narrow bet: spend the smallest amount necessary to learn whether the core idea holds, before spending the much larger amount required to build it fully. Confusing it with a cheap first version of the final product, rather than a test built to be partly discarded, is the single most common way MVPs fail to deliver the learning they were built for.
The businesses that get real value from an MVP are the ones that name the assumption honestly, define success before launch rather than after, and treat the result, whichever way it goes, as the actual point of the exercise rather than an inconvenience on the way to the real product.
