MVP development: the complete 2026 guide for UK SMEs and startups

Q: How much does it cost to build an MVP in the UK in 2026?

UK MVP cost bands in 2026 fall into three rough tiers. A simple MVP with a single core workflow typically costs £8k to £40k. A standard MVP with authentication, a couple of integrations and polished UX costs £25k to £80k. A complex MVP with regulated data, multiple user roles, or AI-enabled features runs £60k to £200k or more. London agency rates sit at the top of each band. Senior .NET contractors in the UK are on around £588 per day in April 2026 according to ITJobsWatch, so a 12-week MVP team of four can easily reach £80k at UK rates.

Q: How long does it take to build an MVP?

A simple MVP usually takes 6 to 12 weeks. A standard MVP with integrations and real onboarding takes 10 to 20 weeks. Complex MVPs in regulated sectors or with AI cores take 3 to 6 months or more. If someone quotes you a full MVP in under 4 weeks, either the scope is tiny or corners are being cut on discovery and instrumentation - both of which come back to bite you post-launch.

Q: What is the difference between an MVP, a prototype and a proof of concept?

A proof of concept (PoC) answers a technical question: can we build this? It is usually internal and disposable. A prototype answers a design question: does this feel right to users? It is often clickable but not functional. An MVP answers a market question: will real users adopt and pay for this? It is functional, instrumented and public. Getting these confused is one of the most expensive mistakes UK SMEs make - you can ship a slick prototype, get applause in the boardroom, and still have no idea whether the product works in the wild.

Q: Should I build a traditional MVP or an AI-first MVP?

A traditional MVP is built on deterministic logic - if this, then that. An AI-first MVP puts a reasoning engine, usually a large language model, at the core of the experience. AI-first makes sense when your product's value comes from interpreting unstructured input (messages, documents, voice) or when an AI layer creates a defensible moat. Avoid AI-first if your workflows are deterministic, your data is thin, you are in a high-compliance sector without governance in place, or if you cannot bound your LLM token spend. For most UK SMEs, a traditional MVP with one or two targeted AI features is the lowest-risk 2026 choice.

Q: What are the 5 stages of MVP development?

The standard five stages are Discovery (1-6 weeks), Design (1-4 weeks), Build (6-20 weeks), Test (2-4 weeks) and Launch and measure (2-8 weeks). Discovery tends to take 10-15% of the budget, Design 15-20%, Build 40-60%, Test 10-20%, and post-launch support around 15-20% of the original budget annually. Skipping Discovery or Test to save money is a classic false economy - both pay back multiple times over.

Q: What metrics should I track for my MVP?

Instrument one north-star metric that directly captures user value, plus two or three activation events and retention checkpoints at day 7 and day 30. Add a Sean Ellis product-market fit survey once you have around 40 active users. Avoid vanity metrics - research shows 73% of startups track things like page views or sign-ups that don't correlate with revenue. Bake measurement into Discovery, not after launch, so you can actually learn from your first weeks in market.

Q: Should I use a UK agency, an offshore team or in-house developers for my MVP?

UK agencies are the highest-cost, lowest-risk option. Offshore teams can cut the bill by 50 to 70% but add coordination overhead, timezone friction and often require stronger in-house technical leadership to manage. Hiring in-house for a pre-revenue MVP usually makes little sense - the cost of a four-engineer UK team runs around £360k a year before you ship anything. For most UK SMEs, the right answer is a UK agency with proven MVP experience, or a hybrid model with a UK technical lead and selected offshore engineers.

Q: When should I NOT build an MVP?

Skip the MVP if your problem is already well-solved and you are just competing on price or UX polish - that is not a market risk, it is a design and sales job. Skip it if you are in a deeply regulated sector where a thin product cannot legally ship (some financial services, medical devices, safety-critical infrastructure). Skip it if your hypothesis can be tested faster and more cheaply with a landing page, a concierge service or a spreadsheet. Not every idea needs code. The MVP exists to test a market risk, not to signal effort.

Q: Do I need to worry about UK GDPR when building an MVP?

Yes, from day one. If your MVP handles personal data - names, emails, payment details, anything that identifies a person - UK GDPR applies. Practical basics: have a lawful basis for processing, minimise what you collect, document a Data Protection Impact Assessment for higher-risk processing, and be ready to report a personal data breach to the ICO within 72 hours of becoming aware of it. Under the Data (Use and Access) Act 2025 this 72-hour rule now also applies to PECR breaches. None of these are barriers to shipping; they are modest engineering decisions that are cheap early and expensive to retrofit.

MVP development - the complete 2026 guide for UK SMEs and startups

Quick answer: A Minimum Viable Product (MVP) is the smallest version of a product that lets you learn whether real users want it. For UK SMEs in 2026, a standard MVP costs roughly £25k to £80k and ships in 10 to 20 weeks. The biggest question of 2026 is not whether to build one - it is whether to build a traditional MVP or an AI-first MVP. This guide covers both, with UK cost bands, a 5-stage process, a .NET/Azure worked example, and the decision frameworks SMEs need to avoid the 68% MVP failure rate.

Every year, thousands of UK SMEs and founders commission a Minimum Viable Product. Most of them will not make it past the first year. An industry analysis of 125 projects found that 68% of MVPs fail after launch - not because the tech is broken, but because the product was built for the wrong user, shipped with no way to measure learning, or padded out with features that delayed real feedback.

The good news is that the failure modes are well understood and largely avoidable. MVP is a discipline, not a product type. Done well, it is the cheapest, fastest way to find out whether your business idea actually works - before you commit the sort of money that keeps finance directors awake at night.

This guide is written for UK decision-makers: founders, managing directors, operations leads, finance directors and first-time CTOs who are considering commissioning an MVP in 2026. It covers what an MVP really is (and what it is not), how much one should cost in the UK right now, how to choose between a traditional and an AI-first approach, the five stages of a well-run build, and the decision frameworks that separate products that survive from those that do not.

Throughout, the focus is on practical decisions with UK-specific numbers. We build on Azure and .NET, so the worked examples lean that way, but the principles apply whatever your stack.

UK context matters here. Business R&D spending on software development hit £10.3 billion in 2024 according to the ONS, 18.5% of all UK business R&D. The British Chambers of Commerce reported in March 2026 that 54% of UK firms are now actively using AI, up from 35% a year earlier. 69% of UK SME employers used web-based software to sell or manage the business in 2024 (Longitudinal Small Business Survey), up from 50% just two years earlier. The SME Digital Adoption Taskforce's final report in July 2025 set the national ambition of making UK SMEs the most digitally capable and AI-confident in the G7 by 2035. Against that backdrop, the question is not whether UK SMEs should invest in software, but how to do it without burning budget.

There is also a sober counterweight. ONS Business Demography data shows only 38.4% of UK businesses born in 2019 were still active five years later. Most ventures do not survive their first half-decade. An MVP is partly a way to buy yourself the right to be in the 38% rather than the 62% - by finding out what actually works, with real customers, before you have bet the house on it.

68%

of MVPs fail after launch, per industry analysis of 125 projects

£25-80k

typical UK cost band for a standard MVP in 2026

54%

of UK firms now actively using AI (British Chambers, March 2026)

38.4%

of UK businesses born in 2019 still active 5 years later (ONS)

In this guide

1. What is an MVP (and what it isn't) 2. Why UK SMEs get MVPs wrong 3. The MVP economics in 2026 4. Traditional vs AI-first MVP 5. The 5-stage MVP process

6. Choosing a tech stack 7. When NOT to build an MVP 8. How to pick a UK MVP partner 9. Pivot, persevere or kill 10. UK compliance and funding 11. Frequently asked questions

Jargon buster

Quick definitions for the terms you'll see throughout this guide.

MVP: Minimum Viable Product - a functional product built with only essential features to test with real users
Prototype: An interactive model (usually clickable wireframes or a visual mock-up) used to test design and user flows, not full functionality or market demand
PoC: Proof of Concept - a small build to answer a technical feasibility question
PMF: Product-Market Fit - evidence that people actually want what you've built enough to pay for or rely on it
Activation: The percentage of new users who reach the point where the product starts delivering real value

North-star metric: The single measure that best captures your product's value delivery over time
RAG: Retrieval-Augmented Generation - giving an LLM access to your own data for more accurate answers
LTV/CAC: Lifetime value over customer acquisition cost - a ratio showing unit economics (3:1 is a rule of thumb for sustainability)
Sean Ellis test: A survey asking users how disappointed they'd be without your product - 40%+ "very disappointed" signals PMF

1. What is an MVP (and what it isn't)

Eric Ries, the founder of the Lean Startup movement who coined the term in 2009, defines an MVP as "the version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort." Note the words: validated learning, least effort. Not cheapest product. Not first release. Not pitch-deck demo.

"An MVP is not a cheaper product - it's about smart learning."

Steve Blank, author of The Four Steps to the Epiphany

The Silicon Valley Product Group, founded by product veteran Marty Cagan, puts it even more sharply: an MVP should be the smallest possible product that is valuable, usable and feasible. Three tests, all of which have to pass. Cagan himself has argued the idea should go further: "an MVP should never be an actual product; it should be a prototype, not a product." That framing helps in the UK SME context, where the temptation to ship something v1-shaped to justify the investment is strong.

This matters because many UK founders, pushed by investor timelines or their own enthusiasm, conflate an MVP with a v1 launch. A v1 launch tries to be a real product, but smaller. An MVP tries to answer a question: will real people, with real problems, use this and pay for it? Those are different briefs, and they produce different software. (If you are still working out whether a custom build is the right route at all - MVP or otherwise - start with our primer on what bespoke software is and when it makes sense.)

"Do things that don't scale. Launch early and talk to users. Make something people want."

Tom Blomfield, founder of Monzo - describing the principles used during Monzo's early days

Monzo's early cards - issued in 2015 under the company's original name, Mondo - were physically stamped with the word "Alpha" and coloured bright coral. A deliberate choice that made early adopters feel special and made the cards visually unmistakable in a bar or at a till. That was not just branding; it was product strategy. The Alpha cards were effectively an MVP - a limited-scope prepaid card that let the team learn how users wanted to use a mobile-first bank before it held a full banking licence. Mondo rebranded to Monzo in 2016 after a trademark dispute, but by then the Alpha programme had already done its job.

The Mondo Alpha card from 2015 - a deliberately scarce, unmissable coral prepaid card used to learn how people wanted to bank on mobile, long before a full banking licence was granted. Mondo rebranded to Monzo in 2016.

MVP vs prototype vs proof of concept vs pilot vs beta

Get these confused and you will spend £40k answering a question you could have answered with a £3k prototype, or ship a prototype to market and call it an MVP. They are not interchangeable.

Artefact	Answers which question?	Typical UK cost	Typical duration	Who uses it
Proof of Concept (PoC)	Can we technically build this?	£5k-£25k	Days to 4 weeks	Internal - CTO, architects
Prototype	Does this feel right to users?	£1k-£15k	1-4 weeks	Design team, a handful of test users
MVP	Will real users adopt and pay for this?	£8k-£200k+ (see section 3)	6 weeks-6 months	Public, or an early-access cohort
Pilot	Does this work end-to-end in a real operation?	Varies with scope	2-12 weeks	A limited live customer group
Beta	Is this stable and performant enough for general release?	Varies with scope	2-12 weeks	A larger pre-GA user base

MVP flavours

Not every MVP needs to be a shippable software product. There are several flavours, and picking the right one can save months and tens of thousands of pounds.

Landing-page MVP - a marketing page describing the product, a sign-up or pre-order button and paid traffic to test demand. Costs hundreds rather than thousands. Validates demand, not usability.
Concierge MVP - you deliver the service manually, openly, to a handful of early customers. They know you're doing it by hand. The goal is to work out what the service should actually do by doing it in person, one customer at a time. The Zappos founder ran this pattern by personally sourcing shoes from local shops and shipping them to buyers as the site's catalogue grew.
Wizard-of-Oz MVP - the front end looks and feels automated; humans run the workflow invisibly behind it. The user thinks they're interacting with software. The goal is to validate whether the automated experience would be adopted, without paying to build the automation. The early Q&A app Aardvark (later acquired by Google) used this to route questions - users thought an algorithm was matching their queries to experts, but real people were doing the matching. Put simply: Concierge is transparently manual, Wizard-of-Oz is secretly manual.
Single-feature MVP - build only the one feature that represents the core value hypothesis, and ship it with almost nothing else around it. This is the flavour people usually mean when they say "MVP".
Piecemeal MVP - stitch together Zapier, Airtable, Typeform, Stripe and a WhatsApp number. Validates the workflow before anyone writes bespoke code.
No-code MVP - use tools like Bubble, Softr, Retool or Power Apps to assemble a functional product without engineering. Faster and cheaper to build; harder to scale. Our low-code and no-code primer covers when these tools fit and when they start to buckle.

Most UK SMEs should sit in a cheaper flavour for longer than they think. If a landing page and a concierge service can kill an idea in two weeks for £2k, that is the best £2k you will ever spend.

"Will Shu co-founded Deliveroo in 2013 in a London flat."

CNBC transcript, April 2018

Deliveroo's earliest MVP was not a polished platform - it was Will Shu running takeaway orders on his own bicycle around south London, with a basic website to take orders. That is the concierge flavour in action. Cazoo's Alex Chesterman took a different route: a pre-launch round of £80m funded a near-complete online used-car platform that sold £10m worth of cars in its first eight weeks. Both worked, because both matched the flavour to the scale of market risk they were facing. There is no single right answer.

2. Why UK SMEs get MVPs wrong

An analysis of 125 MVP projects published in 2025 found 68% failed after launch. The most common root causes were misaligned problem definition, fragile architecture, incorrect assumptions about AI readiness, and poor handoffs between teams. None of those are unfixable. They are patterns that repeat.

Two UK professionals in conversation, one taking notes during a product discovery interview — Most MVP failures trace back to skipped or superficial discovery - the unglamorous work of actually listening to users.

Here are the failure modes we see most often at Red Eagle Tech, and how to avoid each.

Failure mode 1: Over-scoping. "Minimum" stops being minimum.

Every project begins with a tight scope. By week 6, someone has added single sign-on, a dark-mode toggle and an integration with the accounting system "for when we scale". The launch slips by two months, the budget balloons by 50%, and you are no closer to validated learning than you were at the start. The fix: lock scope ruthlessly in Discovery and treat every new feature request as a decision to delay launch. Say "yes, in v1.1" a lot.

Failure mode 2: Under-scoping. Shipping something no one wants.

The opposite failure: the team ships so little that users can't tell whether the product is valuable or not. A "minimum" product that fails to deliver the core value hypothesis is not an MVP - it is just thin. The fix: ask yourself during Discovery "what is the one moment of value this product delivers?" and make sure that moment works. Everything else is optional.

Failure mode 3: No measurement plan.

You launch, hundreds of people sign up, and then you realise you have no idea whether any of them got value. Research suggests 73% of startups track vanity metrics rather than actionable signals, and fewer than 30% of SaaS companies track activation or retention in any structured way. The fix: pick one north-star metric and two or three activation events during Discovery. Wire them into the product on day one.

Failure mode 4: Building for investors, not users.

Your investor wants to see a polished demo. Your users want a tool that solves a painful problem. These are not the same thing, and a product designed for the former will often fail to deliver the latter. The fix: build for users first. A product that works well for 20 real users is more fundable than a slide-ready demo for 0 real users.

Failure mode 5: Confusing MVP with prototype.

Teams stop at a clickable Figma prototype, get nods in stakeholder reviews, and assume that validates market fit. It does not. A prototype validates design. Only a functional product in users' hands validates demand. The fix: know which question you are answering before you start, and do not conflate design acceptance with market acceptance.

Failure mode 6: Deferred observability.

Logging, error monitoring and user analytics get pushed to "after launch" because they don't ship to users. Then something breaks at 2am and you have no idea what happened, or your usage numbers look great but your retention is catastrophic and you can't see it. The fix: instrument from day one. Application Insights on Azure, a front-end analytics tool, and basic crash reporting are effectively free at MVP scale.

"TransferWise had to allocate more than half of its engineering team to fixing the 'basement' - the core technology - after launch."

Taavet Hinrikus, co-founder of Wise (formerly TransferWise)

There is a seventh failure mode that does not get listed often but is worth naming: refusing to accept post-launch technical debt as a cost of speed. Hinrikus's comment about TransferWise points at the uncomfortable truth that a fast MVP almost always carries code you will need to rewrite. Founders who treat that as a failure of the development team, rather than as a deliberate trade, either ship too slowly in the first place or alienate the engineers when the remediation bill arrives. Build the MVP knowing you will pay some rebuild cost later. Budget for it.

3. The MVP economics in 2026

The question every UK founder asks first is "how much will this cost?" The honest answer is that MVP costs vary by an order of magnitude depending on complexity, compliance burden, how much design is required, and where the work is done. Here is what the numbers actually look like in April 2026. For a broader view across the full bespoke-software market (beyond just MVPs), our separate guide to bespoke software cost in the UK covers end-to-end builds, ongoing support and total cost of ownership.

UK cost bands (GBP, April 2026)

MVP tier	Typical scope	UK cost band	Timeline
Simple	One core workflow, basic auth, minimal integrations, lightweight UX	£8k-£40k	6-12 weeks
Standard	Authentication, two or three integrations, polished UX, basic admin, mobile-ready	£25k-£80k	10-20 weeks
Complex	Regulated data, multiple user roles, AI-enabled features, billing, complex integrations	£60k-£200k+	3-6 months+

Sources: synthesised from 2026 UK agency published ranges (Tinderhouse, Square-Root, Ptolemay, Sigli, Empyreal). London-based teams sit at the top end of each band. VAT at 20% applies to UK agency invoices unless you are VAT-exempt.

Infographic comparing UK MVP cost bands in 2026: Simple £8k-£40k over 6-12 weeks, Standard £25k-£80k over 10-20 weeks, Complex £60k-£200k+ over 3-6+ months

UK day rates in April 2026 (ITJobsWatch medians)

Agency pricing ultimately comes from engineer day rates. Current UK medians, taken from ITJobsWatch data for the six months ending 15 April 2026:

Role	Median day rate (UK)	90th percentile	Median permanent salary
Senior .NET Developer	£588	£719	£70,000
Senior Software Engineer (general)	£512	£734	£75,000
Azure Architect	£575	£775	n/a
Azure Engineer	£500	£668	£70,000
Senior DevOps Engineer (London)	£625	£725	n/a
Machine Learning Engineer	£700	£1,000	£75,000-£102,000
Product Manager (tech)	£540	£725	n/a
Senior UX Designer	£513	£629	£70,000 (UK) / £85,000 (London)

Source: ITJobsWatch, medians for the six months ending 15 April 2026. Permanent ML Engineer salary ranges from £75,000 (Robert Half UK) to £102,000 (Robert Half London); senior London AI/ML talent can reach ~£115,500 (Harvey Nash 2026 commentary).

One notable trend: Azure Architect contractor rates fell roughly 8% year-on-year in England (over 11% in London) by April 2026. Cloud talent supply has started catching up with demand after several tight years.

A four-person team (two senior full-stack, one designer, one product manager) at UK contractor rates comes to roughly £8,000 per week. Over a 12-week Standard MVP, that is £96k in day rates alone, which is why agency pricing for a real Standard MVP tends to cluster around £60k-£80k once internal efficiencies and fixed-price risk absorption are factored in.

Stage-by-stage cost split

A well-run MVP distributes budget like this:

Stage	% of total budget	What your money pays for
Discovery	10-15%	Problem interviews, scope definition, measurement plan, architecture choices
Design	15-20%	Wireframes, clickable prototype, usability tests, final UI
Build	40-60%	Engineering, CI/CD, third-party integrations, AI components
Test	10-20%	Internal QA, closed beta, usability checks, performance baselines
Launch and measure	5-10%	Soft launch, instrumentation verification, first-iteration backlog

Ongoing maintenance

Plan for 15-25% of your build cost per year for ongoing maintenance and small-feature work. A £60k MVP therefore has a reasonable year-one total cost of roughly £70k-£75k. Founders who forget this line-item run out of runway mid-iteration - and the code corners you cut to ship quickly tend to turn into technical debt that slows future releases if it isn't budgeted for properly.

Cloud and AI costs

A modest MVP on Azure, AWS or GCP in London costs around £300-£400 per month in baseline infrastructure (storage, compute, a database, a small Kubernetes or App Service footprint). Add CDN, email delivery and a log backend and most MVPs run comfortably under £500 per month until real traffic arrives.

AI changes the picture. LLM inference is usage-based and can scale unpredictably. As of early 2026, OpenAI's gpt-5.3-chat-latest model is priced at $1.75 per million input tokens and $14 per million output tokens. Azure OpenAI Service (which is listed on the UK Digital Marketplace and offers UK data residency) offers similar tiered pricing. An MVP with a moderate AI workload - say a few thousand user sessions per month and 2-4k tokens per session - can run at anywhere from £50 to £2,000 per month depending on model choice. The principle: instrument token usage on day one and put hard spend caps in place before you ship. Section 4 covers the mechanics and the risk of cost runaway in more detail.

UK vs offshore cost comparison

Sourcing model	Typical MVP total (standard tier)	Strengths	Trade-offs
UK agency	£40k-£120k	Same timezone, legal jurisdiction, IP clarity, easier escalation, proven delivery	Highest day rates
UK freelancer(s)	£25k-£80k	Lower rates than agencies, direct relationship	Capacity risk, fewer specialists, IR35 considerations
Hybrid (UK lead + offshore build)	£25k-£70k	UK accountability, lower build cost	Coordination overhead, quality control more dependent on lead
Eastern Europe agency	£15k-£45k	Comparable quality to UK at lower cost, close timezone	Contractual and IP complexity; fewer UK-specific domain experts
India / SE Asia agency	£8k-£25k	Lowest headline cost, large talent pool	Timezone and communication friction, uneven quality, requires strong internal tech leadership
In-house (UK)	£360k+ per year (4 engineers)	Long-term ownership, product knowledge retained	Rarely makes sense pre-revenue; significant fixed cost

Figures synthesised from published 2025-2026 cost comparisons (Code & Pepper, Sevensolvers, agency market data). Actual pricing varies significantly by scope.

UK-specific gotchas

IR35 - if you engage UK contractors directly through their own limited company, IR35 rules may make you responsible for the status determination. Using an agency or umbrella usually moves that burden. Worth a brief legal review before signing.
VAT - UK agency quotes typically exclude VAT. A £60k MVP is £72k with VAT. Not a trap, just something to remember when comparing offshore quotes.
R&D tax relief - some MVP development qualifies for UK R&D tax credits, particularly where you are resolving technical uncertainty. Worth asking your accountant before the build starts so records can be kept correctly.

Want a straight-talking estimate for your idea? These bands cover most MVPs but every project is different. If you'd like a no-nonsense view of what yours might actually cost, timeline, and team shape - and an honest opinion on whether an MVP is even the right move - get in touch for a free 30-minute scoping conversation.

4. Traditional MVP vs AI-first MVP

The biggest strategic question in 2026 MVP development is not what to build but how to build its core. For the first time, founders have a genuine choice between a deterministic product and an AI-first product where a reasoning engine sits at the centre of the experience. If you are weighing the broader build-vs-buy-vs-hybrid decision for AI capability, our guide to custom AI solutions for UK SMEs covers that decision in more depth.

"A Traditional MVP is built on deterministic logic, following fixed if-then rules. An AI-First MVP is probabilistic, built around a reasoning engine and AI-powered features that interpret user intent in real time."

Tinderhouse, Kent/London, January 2026

This is not a cosmetic distinction. The two approaches have different costs, different risks, different team requirements and different product behaviours.

Decision matrix

Factor	Traditional MVP	AI-first MVP
Core logic	Deterministic rules, hand-coded workflows	Probabilistic, LLM- or ML-driven reasoning
Best for	Structured workflows, transactional products, compliance-heavy domains	Unstructured inputs (messages, documents, voice), agentic automation, personalisation
Typical time to launch	10-20 weeks	10-24 weeks (plus longer evaluation harness)
Typical UK cost (standard tier)	£25k-£80k	£40k-£120k (AI engineering adds 30-50%)
Ongoing operating cost	Predictable, scales linearly with users	Usage-based, variable, can spike sharply
Main risks	Feature gaps, slow iteration	Hallucinations, cost runaway, evaluation complexity, prompt injection
Team requirements	Standard product/engineering team	Above + ML engineer or applied AI specialist
Defensibility	Features copied quickly	Data and model operations can become a moat

Side-by-side comparison of Traditional MVP and AI-first MVP across eight decision factors including core logic, typical cost, main risks and defensibility

When AI-first is the right call

Strong case for AI-first

The core user interaction involves interpreting natural language, documents, images or voice
You have (or can obtain) a reasonable volume of data the AI layer can learn from
Your team has the maturity to add observability, evaluation and guardrails
You can put hard budget caps on token usage and tolerate some variability in output quality while you iterate
The competitive alternatives are clunky rule-based tools that users tolerate rather than love

When traditional is the right call

Stay traditional

Your workflows are deterministic (invoicing, booking, CRUD-heavy line-of-business apps)
You operate in a regulated sector where probabilistic outputs would need human sign-off for every decision anyway
You do not yet have the data, evaluation harness or governance in place to deploy AI safely
Your users need predictability more than they need magic
You cannot yet bound your operating cost per transaction

The pragmatic middle ground

For most UK SMEs, the right answer in 2026 is a traditional MVP with one or two deliberately placed AI features. Not everything needs a reasoning engine. A contract-management product with rule-based workflow plus an AI-powered clause extractor is faster to ship, easier to explain to buyers, and less likely to hallucinate its way into a support ticket than a fully agentic system. The AI parts can be deepened in v1.1, v1.2 and onwards as you learn what users actually want.

For worked examples of how this plays out in specific product categories, see our guides to intelligent document processing, AI contract management, and AI-powered customer portals - each is effectively an AI-first MVP template for a specific domain.

Implementation patterns

If you do go AI-first, four common patterns apply:

Wrap-an-LLM - use a hosted model (OpenAI, Azure OpenAI, Anthropic) with prompt engineering and minimal customisation. Fastest and cheapest to start; thinnest moat. Breaks at scale once per-session token costs dominate unit economics.
Retrieval-Augmented Generation (RAG) - feed the model your own data at query time so answers are grounded in your content. Good balance of cost, quality and defensibility for most SME use cases. Azure's current guidance is to chunk source documents at around 512 tokens with a 128-token overlap, retrieve the top 5 candidates, and combine keyword/metadata pre-filtering with semantic ranking to cut expensive context size.
Fine-tuning - train the model on your domain data so it performs better on your specific tasks. More expensive, slower to iterate, but sometimes necessary for specialist domains. One important 2026 constraint: the GPT-5 family is not currently fine-tunable on Azure OpenAI. GPT-4.1 and GPT-4.1-mini do support fine-tuning, but model and region availability changes - always verify in your tenant.
Agentic workflows - the AI uses tools (search, database queries, API calls) to complete multi-step tasks autonomously. Powerful but hard to evaluate and operate. LangGraph, AutoGen, CrewAI and Semantic Kernel all offer agent orchestration. For most MVPs, start with a single well-scoped agent and a deterministic safety shell around it before attempting multi-agent patterns.

Azure OpenAI specifics for UK SMEs

For UK teams, Azure OpenAI Service is usually the pragmatic default: it is on the UK Digital Marketplace, offers UK data residency in UK South and UK West, integrates with managed identity and private networking, and provides the same integration surface as the rest of your Azure stack. A few 2026 specifics worth knowing:

PAYG vs PTUs. Pay-as-you-go pricing is the right choice for early MVPs. Provisioned Throughput Units (PTUs) become financially interesting when you are spending consistently above roughly $1,800-$3,000 per month on inference. A single PTU handles around 108 million input tokens per month at around $720 - roughly $6.67 per million input tokens, which materially beats PAYG once volume is steady.
Semantic Kernel vs LangChain. For .NET/Azure shops, Microsoft's Semantic Kernel is the most natural orchestration framework - it supports dependency injection, structured logging and cleanly integrates with Azure services. For Python shops, LangChain has the broadest ecosystem and is faster to prototype on.
Prompt caching. Azure supports prompt caching on recent models. Cache-read tokens are roughly half price, and repeated system prompts or long reference contexts are where the savings land. Wire caching in from day one on any long-prompt design.
Azure Batch API. For offline, high-volume processing (document ingestion, analytics, overnight workloads), Azure's Batch API offers up to 50% off PAYG pricing. If your MVP touches batch workloads, it is unambiguously worth using.
Evaluation harnesses. RAGAS, DeepEval and Azure AI Foundry's built-in evaluations are now standard for measuring grounding, hallucination and retrieval precision. Bake them into your CI pipeline so every prompt and retriever change gets measured automatically.

Realistic monthly cost scenarios (GBP, April 2026)

Abstract LLM costs are meaningless. Concrete ones tell you what you are actually signing up for. The three worked examples below use current Azure OpenAI and OpenAI public pricing, an exchange rate of $1 = £0.7429, and explicit assumptions:

Use case	Assumptions	Monthly cost (gpt-5 / gpt-4.1)	Monthly cost (mini model)
Customer-support assistant	10,000 sessions/month; 4k input + 2k output tokens each	~£186/mo (gpt-5)	~£13/mo (gpt-4o-mini)
Document processor	500 PDFs/day at 30k tokens each; ingest-only	~£418/mo (real-time gpt-5)	~£209/mo (Batch API 50% off)
Internal RAG chatbot	100 users × 20 queries/day × 5k context + 200 output	~£517/mo (gpt-4.1)	~£103/mo (gpt-4.1-mini)

These are illustrative, not quotes. Model choice can move your costs by an order of magnitude. Prompt caching saves roughly 5-15% in typical workloads; Batch API doubles your money on offline jobs. The practical rule: start cheap, instrument token usage per endpoint and user cohort from day one, and only upgrade models where the quality delta justifies the cost.

Cost-runaway warning Industry horror stories abound of MVPs burning through an entire monthly cloud budget inside 48 hours because of an unthrottled retry loop on a reasoning model. Before you ship any AI feature: set hard per-user and per-endpoint rate limits, set Azure budget alerts, and monitor token usage dashboards daily for the first month. LLM bills are not gradual - they are fine and then suddenly catastrophic.

Cautionary tales: AI MVPs that went sideways

The recent history of high-profile AI products is a useful reminder that launching hard is not the same as launching well. A few named cases from 2024-2025 worth learning from:

Humane AI Pin (2024) - Raised around $240m. Sold fewer than 10,000 units. Acquired by HP after ten months on market and the product was discontinued. The failure mode was classic AI-first overreach: hardware that was not reliable, software that was not ready, battery life that did not last the day, and a form factor users did not want. No amount of prompt engineering can rescue a product whose physical shell is broken.
Artifact (shut down January 2024) - An AI-powered news-feed app built by Instagram's co-founders. Amassed a 160,000-person waitlist. Closed because engagement did not convert into sustained use. The lesson: waitlist signups are a vanity metric. Activation and retention are the real PMF signals.
Forward CarePods (shut down late 2024) - Raised around $650m for autonomous AI-powered medical kiosks. Shut down after repeated technical failures. The lesson: regulated sectors are unforgiving of MVPs that rely on probabilistic systems working correctly without strong human oversight.
Builder.ai (delivery delays 2024-2025) - Promised a deliverable MVP in June 2024 per public customer complaints; delays pushed the first testable release to January 2025. The lesson: "AI will build your app for you" is not yet a reliable procurement strategy for UK SMEs. An experienced partner is still worth paying for.

Sources: Museum of Failure Humane AI Pin exhibit; Altar.io analysis of AI MVP failures; Trustpilot Builder.ai customer reviews.

5. The 5-stage MVP process

A well-run UK MVP moves through five stages. The durations and cost percentages below are synthesised from UK agency benchmarks; your project will vary, but these are the shapes that consistently produce usable products.

1Discovery

1-6 weeks · 10-15% of budget

Surface the riskiest assumptions, validate the problem, lock scope and set the measurement plan.

Artefacts: problem hypothesis, success metrics, prioritised scope, architecture outline.

2Design

1-4 weeks · 15-20% of budget

Translate scope into flows, wireframes and a clickable prototype. Test with real users before a line of code is written.

Artefacts: user flows, Figma prototype, usability test results, final UI.

3Build

6-20 weeks · 40-60% of budget

Engineering of core product. Scrum or Kanban sprints, CI/CD from day one, observability wired in from the first deploy.

Artefacts: working product, test suites, deploy pipeline, instrumented events.

4Test

2-4 weeks · 10-20% of budget

Internal QA, closed beta with invited users, usability testing, basic performance checks.

Artefacts: bug backlog, user feedback, performance baselines, security log.

5Launch & measure

2-8 weeks · 5-10% of budget

Soft launch to a limited audience, verify instrumentation, generate the first-iteration backlog from real behaviour.

Artefacts: production deployment, analytics dashboard, post-launch backlog.

Horizontal flow showing the five stages of MVP development - Discovery, Design, Build, Test and Launch - with typical durations and budget percentages

Discovery in detail

Discovery is the stage where most MVPs succeed or fail before a line of code is written. A good Discovery produces four things:

A written problem hypothesis the whole team agrees with
A single north-star metric and 2-3 supporting activation events
A prioritised scope with a clear "not in this release" list
An architecture outline and a rough cost estimate for Build

Skipping Discovery to save 10-15% of the budget is the most expensive decision a founder can make. The 68% failure rate cited earlier is disproportionately driven by problems that should have been surfaced in Discovery.

Build: the non-negotiables

Regardless of stack, any MVP worth shipping in 2026 should have:

Agile delivery, not waterfall. Short iterations (Scrum or Kanban) match MVP learning loops far better than a big-bang plan. Our agile vs waterfall buyer's guide covers the trade-offs for UK SMEs in depth.
CI/CD from day one. Not something to "do later". Continuous Integration and Continuous Delivery mean every change is built, tested and deployable automatically. On Azure this is 1-2 days of setup with Azure DevOps or GitHub Actions.
Observability from day one. Application Insights (or your equivalent) catches errors, tracks usage, and shows you real user behaviour. Zero to useful in a couple of hours. Skipping this is a false economy you will regret within two weeks of launch.
Environment separation. At minimum, a dev environment and a production environment, with no shared data. Two resource groups in Azure.
A security baseline. Managed identities instead of passwords in config, private networking for databases, Key Vault for secrets, HTTPS enforced everywhere. None of these cost extra on Azure if you set them up at the start.
Automated tests for the core workflow. Not 100% coverage. Enough that you can change something without breaking the one feature the product actually exists to deliver.

Launch and measure

A soft launch to 50-500 users beats a hard launch to 5,000. You are still learning. A soft launch gives you the signal you need without the support load of a full launch. The measurement basics should cover:

Event tracking for every activation and north-star event
Error and crash monitoring (Application Insights, Sentry)
A lightweight user feedback channel (Intercom, Crisp, or even a shared email)
A basic performance dashboard (p95 response time, error rate)
A weekly review cadence where the team looks at the numbers and decides what changes next week

6. Choosing a tech stack for your MVP

The best MVP stack is the one your team can ship fastest on. For UK SMEs in 2026, that usually looks like:

A pragmatic UK MVP stack (.NET + Azure)

Backend: .NET 10 (ASP.NET Core) for APIs and server-rendered pages. Mature, fast, and well-supported by UK talent pools.
Frontend: React or Blazor, depending on team strengths. Blazor pairs naturally with .NET if you don't have a strong React team.
Database: Azure SQL or PostgreSQL on Azure. PostgreSQL tends to be cheaper; Azure SQL integrates more tightly with the rest of the Microsoft stack.
Hosting: Azure App Service for simple MVPs, Azure Container Apps if you need containerisation but want to skip Kubernetes complexity.
Auth: A dedicated identity provider (Microsoft Entra External ID, Auth0, or a self-hosted identity provider). Do not roll your own auth in an MVP.
Observability: Application Insights.
CI/CD: Azure DevOps or GitHub Actions.
AI (if needed): Azure OpenAI Service for UK data residency; Semantic Kernel or LangChain for orchestration.

This stack can carry an MVP from 50 users to 50,000 without architectural rewrites, runs on a small Azure subscription for around £300-£500 per month at MVP scale, and puts you on well-trodden ground for hiring UK engineers later.

Why "boring" usually wins

Every few years, a new framework promises 10x productivity and a new category of startup. By the time you are scaling, the framework has been forked three times and its original maintainers have moved to the next hype cycle. Your MVP does not exist to impress anyone technically. It exists to learn. The stack you pick should maximise the learning-per-pound ratio. Mature, widely-supported tools are rarely the exciting choice, but they almost always ship faster.

When to deviate

Deviate from the default stack when you have a genuine technical reason: a real-time collaboration feature that fits Elixir/Phoenix, a compute-heavy workload that benefits from Rust, a data-science core that reasonably runs on Python. Do not deviate for resume reasons or because a framework is trending on Hacker News.

7. When NOT to build an MVP

Not every idea deserves an MVP. Building one when you shouldn't is the most expensive form of procrastination. Here are the situations where the honest answer is "don't".

Your problem is already solved, and you are just competing on UX

If the market has existing solutions and your advantage is "but nicer", you do not have a market risk, you have a design and sales problem. An MVP validates demand. Demand already exists. Skip to a thorough competitive analysis, a clear UX hypothesis, and a go-to-market plan.

You're in a deeply regulated sector where minimum products can't legally ship

Some financial services products, medical devices, and safety-critical infrastructure cannot legally be released in a minimal state. In these sectors, the MVP concept shifts - you validate with closed-cohort pilots, simulated data, or paper-based workflows rather than a shippable product. Plan for regulatory timelines from the outset.

Your hypothesis can be tested cheaper without code

If a landing page with paid traffic could kill your idea in two weeks for £1,500, write the code later. If a manual concierge service could validate the workflow with ten customers over a month, do that first. Writing code is the most expensive form of market research available.

You're chasing a feature, not a product

"AI-powered X for Y" where X is a thin wrapper around an existing model is rarely a product. It is a feature. Features get acquired or commoditised quickly. Before committing MVP-level investment, make sure the thing you are building is a product users would pay for standalone, not a feature inside someone else's workflow.

You don't have someone who will own it post-launch

An MVP produces learning. Learning is worthless without someone to act on it. If there is no product owner after launch who will read the metrics, talk to users, and decide what changes next, you are funding a nice-looking demo, not a learning machine. Sort the post-launch ownership before the build starts.

Not sure an MVP is even the right next step? Sometimes the honest answer is "write a landing page", "run a concierge service" or "buy the SaaS tool" - not "commission a build". We'll tell you which of these fits your situation before quoting anything. Get in touch for a no-obligation conversation.

8. How to pick a UK MVP development partner

Once you have decided you need an MVP and approximately what it should be, the next question is who will build it. For most UK SMEs, that is a specialist agency or a hybrid team. If you do not have an in-house technical leader to run the engagement, also consider pairing with a fractional CTO - they will pay for themselves several times over by catching scope and supplier problems before they become expensive. Here is how to assess a delivery partner properly.

Questions worth asking

Show me three MVPs you've built in the last 18 months. Anyone who can't show recent work is not an MVP shop.
What's your Discovery process? If there isn't one, or it's "half a kick-off meeting", walk away. Discovery is where the biggest decisions get made.
Who writes the code? The engineers you meet in the sales conversation are sometimes not the engineers who end up on your project. Ask who you'll actually work with.
How do you handle scope change? A rigid fixed-scope contract hurts an MVP, because you learn things during build. A chaotic no-scope contract hurts your budget. Look for phased pricing with clear change-control.
How do you measure MVP success? If the answer is "on-time, on-budget delivery" rather than "did the MVP teach the founder what they needed to learn", the partner is optimising for the wrong thing.
Who owns the IP and source code? Should be you, unambiguously. Get it in writing.
What's your post-launch handover? The answer should cover documentation, credentials, deployment walk-through and a support arrangement for the first 30-60 days.
How do you approach AI features specifically? Ask about evaluation, guardrails, cost controls, and what happens when a model produces a bad output. Answers should be specific, not hand-wavy.

Red flags

"We can have it ready in 4 weeks" for a Standard-tier MVP
Fixed-price contracts with no scope flexibility clauses
No Discovery stage, or Discovery bundled as "a few hours up front"
Vague answers on AI costs and guardrails when you plan AI features
Case studies from 2019
No named engineers - just "our team"
Pricing that is dramatically cheaper than everyone else (look hard for hidden post-launch costs)

Green flags

A named product manager and a named tech lead who will actually be on your project
A documented Discovery process they can show you
Example artefacts: their last Discovery deliverable, their last Figma prototype, their last bug backlog
Willingness to push back on your scope. If every feature you propose gets a "yes!", run.
Clear approach to measurement, with examples of how they helped previous clients learn what they needed from their MVP

9. Measuring success: pivot, persevere or kill

Launching is not the end of the MVP. It is the start of the learning phase. The whole point of building in this shape is that you now have real users and real data to tell you whether to double down, change direction, or stop.

The core metrics

North-star metric - one measure that captures real value delivery. For a SaaS, it might be weekly active paying users. For a marketplace, completed transactions. Pick it during Discovery.
Activation rate - the % of new users who reach the point where the product starts working for them. B2B activation targets tend to be 60%+. If you're under 20%, your onboarding is broken.
Retention (D7, D30) - of the users who signed up in week X, how many came back 7 and 30 days later? Plot as a cohort curve. Look for the shape flattening (indicating habit) rather than going to zero.
Product-market fit signal (Sean Ellis test) - ask active users: "How would you feel if you could no longer use this product?" A PMF product gets 40%+ "very disappointed" once you have ~40 respondents.
LTV/CAC - once you have paying users, calculate lifetime value over customer acquisition cost. 3:1 is the rule of thumb for sustainable unit economics.

Pivot, persevere or kill: the decision framework

Kill

Signals:

Sean Ellis PMF <25%
D30 cohort retention trending to zero
Activation persistently <10%
LTV/CAC clearly <1 with no path to fix it
Multiple pivots already attempted without improvement

Next step: Stop, extract learning, reallocate budget. Killing is not failure - it is the responsible outcome when the data is clear.

Pivot

Signals:

Sean Ellis PMF 25-40%
Retention improving but not yet flattening
A segment loves it, the rest don't
A specific use case is sticky, the main use case isn't

Next step: Iterate on a focused hypothesis. Keep what's working, change what isn't. Typical pivots: target segment, core use case, pricing model, interface.

Persevere and scale

Signals:

Sean Ellis PMF ≥40%
D30 cohort retention flattening at a healthy level
Activation rate meeting sector benchmarks
LTV/CAC ≥3:1 or credible path to it
Users actively recommending the product

Next step: Invest in growth, scale the team, harden the product. The MVP has done its job - the next build is a real product.

These thresholds are heuristics drawn from Lean Startup practice, Sean Ellis's PMF work and mainstream product-management frameworks (Kromatic, Strunk). They are not absolute - context and qualitative signals matter - but they are a reasonable starting point for a conversation the founding team should have every 4-6 weeks post-launch.

Three-column framework showing when to kill, pivot or persevere with an MVP, based on Sean Ellis PMF score, retention, activation and LTV to CAC ratio

What "learning" actually looks like

A healthy post-launch cadence at Red Eagle Tech looks like this: a weekly review of north-star, activation and retention; a fortnightly review of qualitative feedback; a monthly written note summarising what has been learned and what changes next. Nothing fancy. The discipline matters more than the format.

10. UK compliance and funding

Two areas catch out UK MVP founders more than any other: the regulatory minimum, and the funding and tax reliefs they could legitimately tap into. Neither is difficult, but both need attention early - a retrofit is always more expensive than baking them in at Discovery.

The UK compliance minimum for MVPs handling personal data

If your MVP touches personal data - names, emails, payment details, location, anything that identifies someone - UK GDPR applies from the first sign-up. The practical minimum for an MVP:

Identify your lawful basis for processing (usually consent, contract or legitimate interests). Write it down. Reference it in your privacy notice.
Scope a Data Protection Impact Assessment (DPIA) early. A DPIA is mandatory when processing is "likely to result in high risk" to individuals - for example systematic extensive profiling, decisions with legal effects, large-scale processing of special-category data, or deploying new technologies like AI-driven decision-making. If your MVP uses personal data to train an AI model, you almost certainly need one. The ICO has a template.
Minimise what you collect. Every data point you ask for is a risk and a storage cost. If you do not need date of birth or exact address for an MVP, do not collect them.
Wire up a breach-reporting protocol. Under the Data (Use and Access) Act 2025, UK organisations must report notifiable personal data breaches to the ICO within 72 hours of becoming aware. Define "becoming aware" in your internal procedure, name who is responsible, and rehearse the flow once before you launch.
Document data residency and sub-processors. Use UK or EEA hosting where possible. Azure OpenAI on the UK Digital Marketplace gives you UK data residency out of the box, which is often the path of least resistance for regulated SMEs.

ICO guidance for AI-enabled MVPs

The ICO has made clear that AI developers are a scrutiny priority. The ICO's AI and biometrics strategy update in March 2026 confirmed continued focus on large-scale AI developers and agentic systems, with the statutory code of practice on AI and automated decision-making progressing. For any AI-first MVP, the regulator expects you to document your lawful basis for using personal data in training and inference, carry out a DPIA where risks are material, and be able to explain your model's behaviour in human terms. None of that is a blocker for an MVP; it is a two or three day documentation exercise if you do it at Discovery, and a month-long mess if you do it after launch.

Agentic MVPs - those where an AI system autonomously makes decisions or takes actions - get additional scrutiny. Keep a deterministic safety shell around anything with legal or financial effect on users, human-in-the-loop approval for edge cases, and full audit logs of model inputs, outputs and the retrieval or tool calls that backed them up.

GDS AI Playbook for SMEs

The UK Government Digital Service published an AI Playbook in February 2025 with 10 principles for public-sector AI. Most of them translate cleanly to private-sector MVPs: know the limits of AI, use AI lawfully and ethically, maintain meaningful human control over high-impact decisions, manage the full AI lifecycle, pick the right tool for the job, and be open about what you are building. SME teams do not need a public-sector budget to apply these - a short written policy, human-in-the-loop for decisions that affect users, and a basic incident playbook cover most of it.

Sector-specific rules worth flagging

Fintech - if your MVP touches payments, consumer credit, investments, or regulated communications, you may need to enter the FCA Regulatory Sandbox. The FCA expects a genuine need to test, a well-developed testing plan with defined objectives, consumer safeguards and proportionate resourcing - even at MVP stage.
Healthtech - if your MVP could be classed as a medical device, MHRA classification applies. If it is destined for NHS procurement, the Digital Technology Assessment Criteria (DTAC) covers clinical safety, data protection, technical assurance and accessibility. Plan for months, not weeks.
Legal tech - the SRA has published guidance on technology in legal practice. AI-enabled legal drafting tools face particular scrutiny.

UK funding and tax reliefs MVP founders should know

UK companies claimed £7.56 billion in R&D tax relief in 2023-24 (HMRC statistics, September 2025) - £3.15bn under the SME scheme and £4.41bn under RDEC. Not all of that went to MVP-stage companies, but the point stands: the UK tax and grant landscape is genuinely generous to software innovators if you plan around it. The main mechanisms worth knowing:

Don't pay full price for your MVP if you don't have to

Innovate UK Smart Grants - single-company requests range from £25k to £500k, and collaborative projects can reach £2m. SMEs in industrial research can receive up to 70% of eligible costs. The Smart Grants programme was paused in January 2025 for redesign and relaunched as a pilot in spring 2025; check the current competition window on the Innovate UK site.
Innovate UK AI Safety Institute alignment grants - £27m awarded across 60 projects in March 2026, with individual grants ranging from £50k to £1m. Relevant if your MVP has a research-grade AI component.
Made Smarter - up to 50% match funding, capped at £20k, for manufacturing-adjacent SMEs adopting digital or AI tools.
Knowledge Transfer Partnerships (KTP) - 12-36 month projects pairing an SME with a UK university researcher. Typical cost around £8,500 per month, of which SMEs pay only around 33% (the grant covers the rest). Useful when your MVP has a genuine research question.
R&D Tax Relief (merged scheme from April 2024) - RDEC provides a 20% taxable credit on qualifying R&D expenditure. Loss-making R&D-intensive SMEs (R&D ≥30% of total expenditure) can access ERIS: an additional 86% deduction on qualifying costs (186% total) plus a payable credit of up to 14.5% of the surrenderable loss. Qualifying software work must resolve genuine technical uncertainty - not just integrate off-the-shelf tools.
SEIS and EIS - tax-advantaged investment schemes that make it materially easier to raise pre-seed and seed money from UK angels. SEIS gives investors up to £200,000 per tax year in income tax relief. Get HMRC Advance Assurance early, before you pitch.
British Business Bank Start Up Loans - personal loans for UK founders. From 6 April 2026, the fixed interest rate is 7.5% (up from 6%) and eligibility is extended to businesses trading up to 60 months.

Grant sizes and scheme rates change regularly. Check the official Innovate UK, HMRC and British Business Bank pages for the current position before relying on any specific figure. HMRC scrutiny of R&D claims has also tightened since 2024 - documentation standards now matter as much as the work itself.

Thinking about commissioning an MVP? Red Eagle Tech builds MVPs for UK SMEs and startups on .NET and Azure, including AI-first products with Azure OpenAI. We will tell you honestly when your idea can be tested cheaper without code, and when it is ready for a real build. Get in touch for a no-obligation conversation about whether an MVP is the right next step for you.

11. Frequently asked questions

A Minimum Viable Product (MVP) is the smallest version of a product that lets you learn whether your idea actually solves a real problem for real users. Eric Ries, who coined the term, defined it as the version that collects the maximum amount of validated learning with the least effort. An MVP is not a cheap or half-finished product. It is a focused experiment, built to answer one question: will people use this, and pay for it?