The term MVP — minimum viable product — was coined by Frank Robinson in 2001 and popularised by Eric Ries in The Lean Startup. In the decade since, it has become one of the most misused concepts in software development. Founders use it to mean "a cheap version of our app." Developers use it to mean "the first release." Product managers use it to mean "phase one."
None of these definitions capture what an MVP actually is — and the confusion costs the businesses that misunderstand it enormous amounts of time and money.
This guide gives you the correct definition, the practical framework for scoping one, what it costs in 2026, and the build process that separates MVPs that generate useful learning from ones that generate useful nothing.
The Correct Definition of an MVP
An MVP is the smallest thing you can build that tests your most critical business assumption with real users.
Every word in that definition matters:
- Smallest: Not a full product, not a polished product, not a product with every feature you eventually want. The absolute minimum required to achieve the learning objective.
- Tests: The purpose of an MVP is to generate validated learning, not to impress investors or generate revenue (though both may happen).
- Most critical business assumption: Every business has a core assumption — that customers have the problem you think they have, that they will pay for your solution, that your approach solves the problem better than alternatives. Your MVP tests this assumption, not secondary ones.
- With real users: Not with your co-founders, your friends, or a focus group. With the actual people who would pay for what you are building.
What an MVP is NOT
- An MVP is not a "lite" version of your final product with some features cut out
- An MVP is not a prototype (a prototype tests usability; an MVP tests business viability)
- An MVP is not "version 1.0" — it is the version that precedes version 1.0
- An MVP is not an excuse to ship something you know is poor quality
- An MVP is not a product that is barely functional — it must deliver enough value for real users to engage with it genuinely
Types of MVP: Choosing the Right One for Your Situation
Not all MVPs involve writing code. The right type of MVP depends on what assumption you are testing and what minimum build proves or disproves it. From lowest to highest cost:
1. Concierge MVP (£0 – £500)
You manually deliver the service that software would eventually automate, serving a small number of real customers. The customer experiences the outcome; you learn whether they value it enough to pay for it. No software required.
Classic example: Before building a grocery delivery app, you manually take orders via text message and deliver groceries yourself. You learn whether people actually want the service before writing a line of code.
When to use it: When your core assumption is "do customers want this outcome?" — and you can deliver the outcome manually to test it cheaply.
2. Wizard of Oz MVP (£500 – £5,000)
You build a front-end that looks like an automated product, but a human manually fulfils every request behind the scenes. The customer sees a working product; behind the curtain, you are doing everything manually.
When to use it: When you need to test whether customers value the product experience, not just the outcome — but you do not want to build the complex backend automation until you have validated demand.
3. Landing Page MVP (£500 – £3,000)
A single page describing your product with a clear call to action — an email sign-up, a pre-order, or a "join the waitlist" button. You drive traffic to the page (via paid ads, organic search, or personal outreach) and measure conversion as a proxy for demand.
When to use it: Testing whether a specific audience is interested in a product before building anything. A 5% conversion on a landing page from cold traffic is a meaningful signal; a 0.3% conversion tells you something important too.
4. Single-Feature MVP (£5,000 – £30,000)
A functional software product with exactly one core feature — the one that delivers the primary value proposition. Everything else is deferred. Users can access the product, use the core feature, and you can measure their behaviour and satisfaction.
When to use it: When your core assumption requires a working software product to test — and you have validated directional demand with cheaper methods first.
5. Piecemeal MVP (£2,000 – £15,000)
Build the product entirely from existing tools and integrations — Airtable as a database, Webflow as a frontend, Zapier connecting them, Stripe for payments. Nothing custom-built. This approach is dramatically cheaper and faster than custom development, and works for a surprisingly large range of business ideas.
When to use it: When your core assumption does not require a technically differentiated product — where the value is in the service design, not the engineering. Many successful startups ran on no-code stacks for 12–24 months before investing in custom development.
How to Define the Right MVP Scope (The Most Important Step)
The hardest part of building an MVP is not the building — it is the scoping. Most founders scope their MVPs too large, incorporating features that they want in the product but that are not required to test the core assumption. Here is the framework for getting scope right:
Step 1: State your riskiest assumption
Write down the single assumption that, if wrong, would make your business non-viable. Not "can we build this?" — that is an execution assumption. Not "will people use a better version?" — that is too vague. The assumption should be: "We believe [specific customer] will [take specific action] because [specific reason]."
Example: "We believe UK accountants will pay £150/month for software that automatically categorises client receipts using AI, because manual categorisation currently takes 2–3 hours per client per month."
Step 2: Define the minimum test
What is the minimum working thing that would confirm or deny this assumption? In the accounting example: can you manually categorise receipts for 5 pilot accountants, charge them £150/month, and see if they find it valuable enough to renew? If yes, do that before building AI categorisation software.
Step 3: Write a feature inclusion test
For every feature you want to include in the MVP, ask: "Does this feature directly help us test the riskiest assumption?" If the answer is no, cut it from MVP scope and add it to the product backlog. Be brutal. Features that feel essential often are not — they are features you want to build, not features required for learning.
Step 4: Define success criteria before you build
Decide in advance what results would mean the assumption is validated, partially validated, or disproved. Without pre-defined criteria, you will rationalise ambiguous results as success. Write down: "We will consider the assumption validated if X% of test users do Y within Z time period."
The MVP Build Process in 2026
For a single-feature software MVP with a technical development team:
- Discovery (1–2 weeks): Define the core assumption, success criteria, target users, and exact MVP scope. Write user stories for the included features only. This stage prevents the scope creep that destroys MVP timelines and budgets.
- Technical scoping (3–5 days): Senior developer or architect reviews the MVP scope and produces a technical approach document and time estimate. Critical: the estimate should cover only what is in scope, not what is on the backlog.
- Design (1–2 weeks): UX wireframes and high-fidelity designs for the core user journey. For an MVP, design time should be proportional to scope — do not spend 6 weeks designing a 4-screen MVP. Use established design patterns and a component library rather than creating a custom design system.
- Development (4–10 weeks): Build the MVP. Weekly demos with stakeholders. Any new feature requests during the build go to the post-MVP backlog, not into the current scope.
- Launch with real users (ongoing): Release to your test cohort and measure against your pre-defined success criteria. Collect qualitative feedback through user interviews alongside quantitative usage data.
- Decision point: Based on results, decide: build the full product (assumption validated), pivot the approach (assumption partially validated with learnings), or stop (assumption disproved — better to know now than after £200,000).
MVP Development Cost in 2026: UK and USA
| MVP Type | UK Cost | USA Cost | Timeline |
|---|---|---|---|
| No-code / piecemeal MVP | £2,000 – £8,000 | $3,000 – $12,000 | 2–5 weeks |
| Simple web app (single feature) | £8,000 – £25,000 | $14,000 – $45,000 | 6–12 weeks |
| Mobile app MVP | £15,000 – £45,000 | $25,000 – $80,000 | 10–20 weeks |
| Marketplace MVP | £25,000 – £70,000 | $45,000 – $120,000 | 14–24 weeks |
| B2B SaaS MVP | £20,000 – £60,000 | $35,000 – $110,000 | 12–20 weeks |
Why does an MVP cost this much? Because a genuine MVP is not a prototype or a wireframe — it is production software that real users can use. It needs to be reliable, secure, and functional enough for real engagement. The cost reflects real engineering work, not just mockups. An "MVP" that crashes under real use or loses user data is not an MVP — it is a failed product that produces no useful learning.
The Most Common MVP Mistakes (And How to Avoid Them)
Mistake 1: Building for investors, not for learning
The pressure to impress investors leads founders to build polished, feature-rich MVPs that look impressive in a demo but are far larger than needed to test the core assumption. Build for learning first. Investors worth working with understand what a genuine MVP is.
Mistake 2: Not talking to users before building anything
The most common — and most expensive — MVP mistake is building in a room and then presenting it to users. Talk to 10–20 potential users before writing a line of code. Discover whether they have the problem you think they have, how they currently solve it, and what they would actually pay for. This research can save £30,000–£80,000 in rework.
Mistake 3: Building the MVP instead of selling it
Many founders hide behind building while avoiding the harder work of sales and customer validation. If you can manually deliver your service to 5 paying customers before building anything, do that first. The learning from real paying customers is worth 100x the learning from free beta users.
Mistake 4: Scope creep dressed up as MVP features
Every week of development, new features feel essential and get added to the MVP scope. The project that should have launched in 8 weeks launches in 20, costs three times the estimate, and is no longer a minimum viable product — it is a medium viable product that took a year to build. The discipline to say no to features is the hardest part of MVP development.
Mistake 5: Choosing the wrong MVP type
Building a full software product when a concierge or Wizard of Oz MVP would test the same assumption for 10% of the cost is one of the most avoidable MVP mistakes. Before starting any technical build, ask: "Can we test this assumption without building software?"
After the MVP: What Comes Next
An MVP is not a finished product — it is the start of a product development cycle. After launch:
- Analyse your success criteria data against pre-defined thresholds
- Conduct structured interviews with the users who engaged most deeply
- Document what you learned — validated assumptions, disproved assumptions, unexpected discoveries
- Decide: build the full product, pivot, or stop. Make this decision explicitly, based on data, before you start the next build cycle
- If building the full product: take the learnings into a proper product specification and development roadmap. The MVP taught you what users value — now build the best possible version of that
Frequently Asked Questions
How is an MVP different from a prototype?
A prototype tests usability and design — it looks like the product and demonstrates how it works, but has no real functionality. An MVP is a functional product that real users can use to accomplish real tasks. A prototype is tested in a controlled session; an MVP is used independently by real users in their actual environment.
Should my MVP be free or paid?
For most B2B and SaaS products, charge from day one — even a nominal amount. Free users behave differently from paying users. If nobody will pay even a small amount for your MVP, that is an important learning. If they do pay, you have validated willingness-to-pay, which is one of the most critical business assumptions.
How long should an MVP take to build?
The rule of thumb: if your MVP takes longer than 12 weeks, you have scoped it too large. Most genuine MVPs should be achievable in 4–12 weeks with a small, focused team. If the timeline is longer, revisit your scope and cut ruthlessly until you reach the true minimum.
What is the difference between an MVP and a beta?
An MVP is about validating the core business assumption — it is a learning exercise. A beta is about validating a more complete product before a public launch — it is a quality exercise. An MVP comes before a beta; a beta comes after the core assumption is validated and you are building the real product.
If you are ready to build an MVP and want a development team that will help you scope it correctly — not just build what you ask for, but challenge you to find the minimum that tests the right assumption — we would like to talk to you. We have built MVPs for founders across the UK and USA, and we are honest when a concierge MVP will serve you better than a software build.