“Minimum viable product” is one of the most misused phrases in software. Founders use it to mean “cheap version”. Investors use it to mean “proof it works”. Agencies sometimes use it to mean “whatever fits your budget”. Those are three different products, and building the wrong one is the most expensive mistake in early-stage software.
The original definition, from Eric Ries, is precise and worth holding onto: an MVP is the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort. Note what that sentence does not say. It does not say “cheapest”. It does not say “fewest features”. It says maximum learning, least effort. The MVP is a measuring instrument, not a discount product.
The one question your MVP must answer
Before scoping anything, write down the single assumption that, if wrong, kills the business. Everything in the MVP exists to test that assumption; everything else waits.
Common riskiest assumptions look like this:
- Demand risk — “Will anyone pay for this at all?”
- Usability risk — “Can a non-technical user complete this workflow without training?”
- Feasibility risk — “Can we actually extract this data accurately enough to be useful?”
- Economics risk — “Does the cost per transaction leave a margin?”
Each of these implies a very different MVP. If your risk is demand, a landing page with a payment button may genuinely be enough. If your risk is feasibility, you need real engineering on the hard part and can fake everything around it. Scoping an MVP without naming the risk first is how teams spend £40,000 building polished settings screens for a product nobody wanted.
What actually belongs in an MVP
A useful test: for every proposed feature, ask “if we remove this, does the experiment still produce a trustworthy answer?” If yes, cut it. Applied honestly, this usually leaves a surprisingly small surface.
| Usually in scope | Usually out of scope |
|---|---|
| One core workflow, end to end | Multiple user roles and permission tiers |
| Basic auth (email + password, or a provider) | SSO, 2FA, SCIM provisioning |
| Manual admin via database or simple back office | Full admin dashboard with analytics |
| One payment path, if money is the test | Refunds, dunning, multi-currency, invoicing |
| Instrumentation to measure the experiment | Custom reporting suite |
| Works well on the devices your testers use | Full cross-browser and native mobile parity |
Note that “manual admin” appears in the in-scope column. Doing things manually behind the scenes — sometimes called a concierge or Wizard-of-Oz MVP — is not cheating. If ten customers a week is a valid test, a human can process them while you learn what to automate. Automating first means guessing at the process before you understand it.
What an MVP is not allowed to skip
Two things are non-negotiable even at minimum scope. The first is instrumentation: if you cannot measure whether users completed the core action, you have built a demo, not an experiment. The second is basic security: real user data means real obligations. Hashed credentials, HTTPS, sensible access control, and no secrets in the front end are table stakes, not phase two. Skipping them does not save meaningful time and creates liability from day one.
MVP cost: what the ranges actually mean
Cost is driven by integration count, data complexity, and how much of the workflow must be automated — not by the number of screens. Broadly, in the UK market:
| MVP type | Typical cost | Typical timeline |
|---|---|---|
| Validation MVP (landing page, waitlist, manual fulfilment) | £1,500–£5,000 | 1–3 weeks |
| Single-workflow web app (auth, one core flow, basic data) | £8,000–£20,000 | 4–8 weeks |
| Integrated MVP (2–3 third-party systems, payments, roles) | £20,000–£45,000 | 8–14 weeks |
| Technically hard MVP (ML, real-time, regulated data) | £45,000+ | 3–6 months |
If a quote sits far below these ranges, look at what is being excluded — usually testing, deployment, or the integration work that turns a prototype into something real users can touch. If it sits far above, the scope has probably drifted past “minimum” into “version one”. You can sanity-check your own numbers with our software project cost estimator.
MVP in an agile process
People often conflate “MVP” with “first sprint output”. They are different. In agile delivery, each increment should be potentially shippable; the MVP is the specific increment at which you have enough product to run the experiment with real users. It might land after two sprints or after six.
The practical consequence is that your backlog should be ordered by risk, not by natural build order. Teams instinctively build foundations first — user management, settings, admin — because it feels tidy. But foundations rarely carry risk. Build the uncertain part early, while there is still budget to react to what you learn.
How to know the MVP worked
Define the success threshold before launch, in writing. “We will consider this validated if at least 30% of invited users complete the core workflow twice in the first fortnight.” A number you set in advance is the difference between learning and rationalising. Without it, every result looks like encouraging early signal.
The most common MVP mistakes
Building for the demo, not the user. Investor-ready polish and user-ready function are different goals. If you need a pitch asset, a prototype is cheaper than a product.
Treating the MVP as version one of the codebase. Some MVPs should be deliberately disposable. Decide up front whether this code is a scaffold or a foundation, and let that decision drive the engineering standard. Both are legitimate; pretending is not.
Shipping to no one. An MVP with no recruited users is not an experiment. Line up your first cohort before the build finishes, not after.
Scope creep by sympathy. Every stakeholder has one small addition. Each is reasonable; collectively they are a different product. Keep a “version two” list visible so ideas are captured rather than argued about.
Deciding what to do next
After the experiment you have three honest options: persevere (the assumption held — invest in hardening and scale), pivot (the assumption failed but you learned where the real value sits), or stop (the assumption failed and there is no adjacent opportunity). A well-scoped MVP makes all three cheap. That is the entire point: not to build software quickly, but to make being wrong survivable.