What Is The Difference Between An MVP, A Prototype And A Proof Of Concept?

Most of the money wasted on early-stage software goes on the wrong artefact. A founder spends £40,000 on an MVP to learn whether a data feed can be integrated, when a developer could have answered that in nine (or less) days for £4,000.

The words get used loosely, and suppliers are partly to blame. “Prototype” is stretched to mean anything from a napkin sketch to a working app, and “MVP” has quietly come to mean “the whole product, but cheaper”.

The useful way to tell them apart has nothing to do with how much code is in them. It is about which unknown you are trying to remove.

The stakes are not theoretical. CB Insights’ 2026 analysis of 385 startup post-mortems found poor product-market fit in 43% of failures, which is exactly the unknown these three instruments exist to remove.

Here is how each works, what they cost in the UK, which one qualifies for R&D tax relief, and why keeping the first two is usually a mistake.

What Is a Proof of Concept, and What Does It Prove?

A proof of concept is a short technical experiment answering one question: can this be built, with this technology, to the standard we need? It is built for your own engineers rather than for customers, and it proves feasibility rather than desirability.

A PoC is deliberately narrow. No interface worth looking at, no error handling, no security model, and often no persistence beyond a file on someone’s laptop.

What a PoC Deliberately Leaves Out

• Design. Nobody outside the team should be shown it, and nobody should judge it on appearance.
• Security, authentication and access control, because there are no real users.
• Error handling and edge cases, unless the edge case is the thing being tested.
• Scale, unless the question is specifically about throughput, latency or cost per transaction.

Typical questions a PoC settles: can we extract structured data from these thirty-year-old PDF scans at better than 95% accuracy? Will this legacy ERP give up the records we need?

Model accuracy questions belong here too. Whether a model performs well enough on your real data is a measurable technical fact, which is why custom AI projects should almost always start with a PoC rather than a build.

The Technical Spike Is the Same Idea, Smaller

Engineers call the compressed version a technical spike, a term from extreme programming. The original XP practice puts a pair of developers on the problem for a week or two, writing the simplest possible code to learn something and then reporting back.

Modern teams often run them shorter, at two to five days. The output of a spike is a decision rather than a deliverable, and if your unknown is contained enough it is the cheapest instrument in the box.

What You Should Receive at the End

A written technical memo is the deliverable, not the code. It should state the question, the method, the measured result and the recommendation in plain language.

Ask for the numbers behind it: accuracy figures, response times, API rate limits and the quirks nobody warned you about. Those findings feed straight into requirements capture for the real build.

What Does a Prototype Do That a Proof of Concept Cannot?

A prototype puts a simulated version of the product in front of human beings to test whether the design makes sense to them. The proof of concept versus prototype distinction is audience: a PoC convinces your engineers, and a prototype tells you whether users understand what you have designed.

The Fidelity Scale

Prototypes exist on a scale. At the low end, pen-and-paper wireframes sketched in an afternoon, and at the high end a clickable Figma file that behaves closely enough to a real app that testers forget it is fake.

Almost none of it is code. Design tools and no-code builders produce something a user can click through without a developer touching a repository.

AI-assisted design tooling has pushed the cost of the high-fidelity end down sharply in the last two years. That changes the arithmetic in favour of prototyping more, not less, and the same shift is reducing the cost of proof of concept work at the technical end.

What a Prototype Is Good at Catching

• Navigation people cannot follow, which is the most common finding by some distance.
• Steps in a workflow that make sense to you and to nobody else.
• Fields users refuse to fill in, and the ones they expected and did not find.
• Vocabulary mismatches, where your label is not the word the industry uses.

How Many People You Need to Test With

Fewer than most people assume. Nielsen Norman Group’s long-standing finding is that five users surface roughly 85% of usability problems in a qualitative study, and that testing beyond that in a single round adds little.

The better use of the same budget is three rounds of five, with a design change between each. One round of fifteen tells you the same thing three times.

Run it before development starts, when changing your mind costs an hour rather than three sprints.

Where Prototypes Mislead

A prototype tells you nothing about performance, running cost, data quality or anything that only shows up at volume. It also cannot tell you whether anyone will pay, because nothing is at stake for the person clicking.

One practical warning: if you test with real customer records, UK GDPR applies to your test environment as much as your live one. The ICO’s data protection by design guidance points to masking, randomisation or generalisation, and pseudonymised data is still personal data.

How Is an MVP Different From Both?

An MVP is a real product, released to real users, built to answer a commercial question rather than a technical or design one. It is the only one of the three where money can change hands and where the code is meant to survive.

Eric Ries defined the minimum viable product 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. The emphasis sits on learning rather than on minimum.

What Minimum Actually Means

One complete user journey, built properly, with authentication, a payment route if you intend to charge, analytics, and hosting that will not fall over. Everything outside that journey waits.

Minimum applies to scope, not to quality. An MVP with no tests and no monitoring is not lean, it is a code rescue waiting to happen.

We set out what an MVP is in more detail separately, including how to choose the journey you build first.

The MVP Is the Only One That Tests Demand

Product-market fit is a demand fact. You cannot infer it from a prototype test, because enthusiasm in a user session is free and a card payment is not.

That is also why an MVP is the slowest and dearest of the three. It is also the one investors expect to see, and SEIS advance assurance lets a UK company raise up to £250,000 under the scheme, which is the budget most first builds are sized against.

What You Should Receive at the End

A deployed product on infrastructure you control, plus the repository, deployment scripts, test suite and documentation. If the handover is a login and nothing else, you have bought a dependency rather than an asset.

How Do the Three Compare Side by Side?

The clearest way to see the difference is by the question each one answers and what happens to the code afterwards. Two of the three are designed to be thrown away.

	Proof of concept	Prototype	MVP
Question it answers	Can this be built at all?	Is this the right thing to build, and does the experience work?	Will anyone actually use this and pay for it?
Who it is for	Your engineers and technical decision makers	Target users, designers and internal stakeholders	Real paying customers in the open market
Built with production code	No. Scripts and shortcuts, no security or error handling	Rarely. Wireframes, a design tool or a no-code builder	Yes. Tested, deployed, monitored and maintained
Thrown away afterwards	Almost always, and it should be	Yes. The design decisions survive, not the artefact	No. It is the first version of the real system
Typical duration	1 to 4 weeks, or a 2 to 5 day spike	2 to 6 weeks including test sessions	8 weeks to 6 months depending on scope
What success looks like	A clear yes or no on feasibility, with evidence	Users completing the core task unaided, and asking for it	Signups, retention and revenue from strangers
Likely to qualify for R&D relief	Often, where genuine technical uncertainty exists	Rarely. Design validation is not a technological advance	Only the components resolving real uncertainty

What You Actually Get for Your Money

Artefact	Deliverables to ask for in the statement of work
Proof of concept	Written technical memo with the question, method, measured results and a recommendation; the spike repository, archived; a list of assumptions that turned out to be wrong
Prototype	The clickable file with edit access; user test recordings or notes; a written summary of design decisions and what changed between rounds; the deferred-ideas list
MVP	Deployed product; source repository transferred to your account; deployment scripts and environment documentation; test suite; analytics configured; a v2 backlog

Write these into the engagement before it starts. They are the difference between an artefact you can act on and a conversation you half remember, and they belong alongside the other terms in a software development contract.

What Does Each One Cost in the UK?

A proof of concept typically runs £5,000 to £20,000, a prototype £5,000 to £25,000, and an MVP from around £15,000 for a genuinely single-journey build up to £80,000 once you have multiple roles, payments and integrations.

Those are typical UK agency figures from delivery experience rather than published data. They move mostly on the integration work sitting behind whatever you are testing.

Artefact	Typical UK cost	Duration	What drives the number
Technical spike	Under £5,000	2 to 5 days	One question, one pair of developers, no integrations
Proof of concept	£5,000 to £20,000	1 to 4 weeks	Integration access, data preparation, how many systems are involved
Prototype	£5,000 to £25,000	2 to 6 weeks	Number of screens, fidelity, how many rounds of user testing
MVP, single journey	£15,000 to £40,000	8 to 14 weeks	One user role, one payment route, minimal integrations
MVP, multi-role	£40,000 to £80,000	3 to 6 months	Several roles, admin tooling, third-party integrations, compliance
Marketplace or regulated MVP	£80,000+	4 to 8 months	Two-sided flows, payments regulation, audit and reporting

Those bands sit inside the wider picture set out in how much bespoke software development costs, which covers what happens after the first release.

What Moves the Number

• Integration count. Each third-party or legacy system adds discovery, credentials and failure handling.
• Data condition. Clean data in a system with an API is cheap, and PDFs on a file share are not.
• Regulation. Payments, health and financial services each add compliance work before a single user arrives.
• Roles. Every additional user type roughly adds a journey, and journeys are the unit of cost.

Get the drivers into the brief rather than the estimate. How to get a quote for software development covers what a supplier needs before a number means anything.

The Cost of Buying the Wrong Instrument

Take a founder whose real unknown is whether a legacy warehouse system will release stock data. A PoC answers it in two weeks for about £8,000.

Building an MVP to find the same thing out costs £35,000 and four months, and the answer arrives in week eleven when the integration work finally starts. That is roughly four times the cost and a lost quarter.

The error is common because an MVP feels like progress and a PoC feels like delay. It is the other way round.

See how our MVP Launchpad works

Which One Should You Build if Your Biggest Unknown Is X?

Name the thing that would kill the project if the answer went against you, then pick the cheapest instrument that answers it. In most cases that is not an MVP.

If your biggest unknown is…	Build this	Because
An integration with a third-party or legacy system may not be possible	Proof of concept	Pure feasibility, and a fortnight settles it
An AI model may not be accurate enough on your real data	Proof of concept	Accuracy is measurable with no product around it
The system may not hit a latency, throughput or cost target	Proof of concept	Load behaviour is a technical fact, not a design opinion
Users may not understand the workflow you have designed	Prototype	Comprehension is only testable by watching people try
You cannot choose between three interface directions	Prototype	Cheaper to build all three in a design tool than to argue
Nobody may want this at all	Neither. Test demand first	A landing page with a real price, or ten paid pilots run by hand
People may not pay, or not enough	MVP	Only a live product with a payment route proves that
The business model may not work at scale	MVP, then instrument it	Retention and unit economics need months of real use

The pattern worth noticing: four of these eight are answered without building a product. That is where the savings live.

Name the Killer Question First

Write one sentence: if this turns out to be false, we stop. Everything else is a preference, and defining the goals and objectives for the project is how that sentence gets agreed rather than assumed.

If you cannot name it, that is itself the finding. Teams that cannot state the killer question tend to be stuck in analysis paralysis rather than short of information.

How Do You Score the Decision?

Rate your three risks out of five: technical feasibility, design comprehension, and market demand. Whichever scores highest is the artefact you should commission first, and a tie between two of them means run both in parallel.

The three risks are independent, which is why a rigid sequence wastes time. This table turns that into a decision you can put in front of a board.

Risk	Score 1	Score 5	If highest, build
Technical feasibility	Well-trodden technology, no unusual integrations	Unproven approach, legacy systems, or model accuracy in doubt	Proof of concept
Design comprehension	Replacing a process users already know	A new workflow nobody has seen before	Prototype
Market demand	Existing customers have asked and committed	Nobody has paid for anything like it yet	Test demand, then MVP
Regulatory exposure	No personal or regulated data	Payments, health records or financial advice	PoC plus a compliance review
Internal ownership	A named product owner with authority	Nobody senior available to decide weekly	Neither. Fix this first

How to Read Your Score

The internal ownership row is a veto rather than a score. A project without a decision maker will fail whichever artefact you commission.

If technical and design risks are both high, run the PoC and the prototype at the same time with different people. They cost different money and answer different questions, and a fractional CTO is often the cheapest way to judge the technical half if nobody internal can.

Which of the Three Qualifies for R&D Tax Relief?

Usually the proof of concept, sometimes parts of the MVP, and rarely the prototype. HMRC relief follows technological uncertainty, and a prototype tests whether users understand a design rather than whether something can be built.

No competitor guide on this subject mentions R&D relief at all. For a UK company it can change the effective cost of the whole exercise.

What HMRC Actually Asks

The test sits in HMRC’s guidance on the meaning of R&D, which says relief applies where a project seeks an advance in overall knowledge or capability in a field of science or technology.

The advance has to be against what a competent professional in the field could readily work out, not against what your own team happened to know. Uncertainty exists where it is not readily deducible whether something is feasible, or how to achieve it in practice.

Relief is claimed under the merged R&D expenditure credit scheme for accounting periods beginning on or after 1 April 2024, at a headline above-the-line credit of 20%, which is itself taxable.

Why a PoC Usually Qualifies and a Prototype Usually Does Not

A PoC is definitionally an attempt to resolve a technical unknown, which is the same sentence HMRC uses. That alignment is why it is the strongest of the three for a claim.

A prototype tests comprehension. Users not understanding your navigation is a design finding, not a technological uncertainty, so the work rarely meets the test however much it cost.

An MVP is mixed. The components resolving genuine uncertainty can qualify, and the rest of the build will not, so keep the time records separated from day one across the development lifecycle.

What HMRC Excludes

The software-specific guidance rules out business requirements gathering, configuring existing software to your own requirements, routine adaptation, confirmatory testing that does not feed back into design, and deployment activity.

Keep a contemporaneous record of what was uncertain and what you tried. Claims fall over on evidence rather than eligibility, which is also true of the wider meaning of R&D as HMRC applies it.

Can Grant Funding Pay for a Proof of Concept?

Sometimes. Innovate UK feasibility competitions fund up to 70% of eligible costs for micro and small organisations, 60% for medium and 50% for large, where the project has a genuine technical unknown.

How Innovate UK Feasibility Funding Works

The Innovate UK funding rules set the intervention rates, and each competition sets its own project size and duration. Ranges vary widely between competitions, from tens of thousands to several hundred thousand pounds.

Check what is actually open before building a plan around it. The open-to-all Smart Grants route has been paused since 2025, so live funding now comes through themed competitions instead.

What Grant Money Will Not Fund

Grants pay for finding out whether something works. They do not pay for building a booking system out of existing frameworks, however new it is to your business.

The same distinction that decides an R&D claim decides a grant application. If a competent professional in the field could tell you the answer, there is no uncertainty to fund.

What Changes in a Regulated Sector?

Two things: what data you can put in a PoC or prototype, and what approval you need before an MVP reaches real users. Both add weeks, and both are cheaper to plan for at the start than to discover at launch.

Using Real Data in a PoC or Prototype

UK GDPR applies to development and test environments. Purpose limitation means data collected to deliver a service cannot simply be repurposed for testing unless the new purpose is compatible or you have a fresh lawful basis.

Pseudonymised data is still personal data. Only true anonymisation takes information outside the regime, which is why synthetic test data is usually the faster route for a PoC.

There is one honest exception. Where the PoC question is about your real data’s quality, synthetic data cannot answer it, so plan the lawful basis rather than working around it.

Fintech, Health and Public Sector Routes

Financial services have a formal route for testing with real customers. The FCA Regulatory Sandbox accepts applications at any time and is designed for exactly the stage between prototype and MVP.

Health technology has a different gate. The NHS Digital Technology Assessment Criteria set out what a supplier must evidence on clinical safety, data protection, security, interoperability and usability before an NHS organisation buys.

Read the criteria during the prototype stage, not after the MVP is built. Retrofitting clinical safety documentation into a finished product is close to a rebuild, and the same holds for any platform choice made without the compliance requirement in view.

What Should Be in the Contract Before You Commission Any of Them?

A named deliverable, an engagement model matched to the uncertainty, IP assignment on payment, and an explicit statement that the artefact is throwaway where it is. The last one is what stops you paying twice.

Procurement is missing from every competitor guide on this topic. It is also where the avoidable money goes.

Artefact	Engagement model that fits	IP and code terms	The clause that matters most
Technical spike	Fixed price. One question, one timebox	Findings assigned to you; code has no value	A written memo is the deliverable, not a demo
Proof of concept	Fixed price on a defined question, or a capped timebox	Findings and repository assigned on payment	Success is a clear answer, including a no
Prototype	Fixed price per round, priced by screens and sessions	Design files transferred with edit access	You own the file, not a view-only link
MVP	Capped time and materials, or fixed price per milestone	Full IP assignment on payment, repository in your account	Acceptance criteria agreed before each milestone starts

Fixed Price, Time and Materials, or a Timebox

Fixed price suits a PoC because the question is narrow and the answer is binary. It suits an MVP badly, because scope moves as soon as real users touch it.

Capped time and materials is the usual middle ground for a build: billed on actuals, with a figure the supplier cannot pass without sign-off. Which model you choose is one of the first decisions in getting a software project started.

The model matters more when the work sits outside your own team. Outsourced delivery needs the deliverable named in writing, because nobody will be in the room to infer what you meant.

How to Avoid Paying Twice

Say in the contract that the PoC is throwaway, and price the real build as a separate engagement from a clean specification. Suppliers who plan to promote the PoC will tell you at that point.

Then check the exit terms on the build itself. Repository access, documented environments and a paid handover window are the three that decide whether you can change supplier, and what should be in a software development contract covers the rest.

Do You Need All Three, and Should You Keep the Code?

No, and no. Most projects need one or two of the three, rarely in a rigid sequence, and both the PoC and the prototype should be deleted rather than promoted into the product.

The Sequence Is a Guideline, Not a Process

The textbook order is PoC, then prototype, then MVP. Real projects skip steps constantly, and they are right to.

A booking system on well-trodden technology has no feasibility question, so there is nothing for a PoC to prove. An internal tool replacing a spreadsheet may need neither, because demand is a known fact and the design follows the existing process.

Some projects run a PoC and a prototype at the same time, because the technical and design unknowns are independent. The question is which unknowns you have, not which stage gate you are standing at.

Why Tidying Up the Prototype Is the Expensive Mistake

This is the moment a lot of budgets quietly go wrong. A PoC works, everyone is delighted, and someone asks whether the team can just harden it rather than starting again.

The answer is almost always no. PoC code has no tests, no input validation, no authentication model, no logging, no migrations, and hard-coded credentials that were fine on a laptop and are not fine in production.

The cost shows up later rather than immediately, which is what makes it easy to accept. McKinsey’s 2020 survey of 50 CIOs at billion-dollar companies put technical debt at 20% to 40% of the value of an entire technology estate before depreciation, with 10% to 20% of the new-product budget diverted into servicing it.

Promoted prototypes are a reliable source of that debt. A good share of the rescue work we take on began as something only ever meant to prove a point.

What You Should Keep

• The PoC’s findings: benchmarks, accuracy figures and API quirks, written down.
• The prototype’s design decisions, and the recordings of users struggling with them.
• The list of things you deliberately deferred, which becomes your v2 backlog.
• Nothing else. Archive the repositories and start the real build clean.

Then build it properly, as bespoke software development rather than an extended experiment.

Whether that lands as a web application or a mobile app is a downstream decision, and it is much easier to make once the unknowns are gone.

Engineering-led work shows the pattern clearly. Our CAD engineering project with QuickWells needed the technical question settled before anyone designed a screen.

Related Guides

Related: What Is an MVP in Software Development?

Related: How AI Reduces the Cost of PoC Software Development

Related: How AI-Driven Development Accelerates MVP Software Implementation

Related: How Much Does Bespoke Software Development Cost?

Related: How Much Does Software Development Cost?

Related: Custom AI Software Development: The Secret to Scaling Your Business

Frequently Asked Questions