What Is a Proof of Concept? PoC vs Prototype vs MVP

A proof of concept (PoC) is a small, quick piece of work that answers one question: can this idea work? In software it usually means building just enough of the risky part, such as an integration, an AI model running on your own data or a tricky calculation, to find out whether it holds up before you pay for the whole product. The term is used outside software too (the technology readiness scale used by UKRI’s Science and Technology Facilities Council has a “proof-of-concept” level), but this article is about software products.

Founders and product owners usually meet three terms at once: proof of concept, prototype and MVP. In short, a proof of concept tests whether something can be built, a prototype tests whether people will understand and want it, and an MVP tests whether real customers will use it. Below we define each one, compare them in a single table with our published prices, explain the discovery phase that comes before any of them, and show how to pick what to fund first. If you already know you need an idea scoped, our discovery sprint starts from £4,000.

Key takeaways

• A proof of concept tests whether an idea is technically possible. It is built to learn, so the code is often thrown away.
• A prototype tests whether people understand and want the product. An MVP is a live, working product with the smallest set of features that tests real demand.
• Choose by your riskiest assumption. Technical doubt points to a proof of concept, usability or investor doubt to a prototype, and demand doubt to an MVP.
• Our published starting prices are a discovery sprint from £4,000, discovery through to a clickable prototype from £8,000 and an MVP build from £15,000, live in around three months.
• You do not need all three in every project. Skip the stages whose question you can already answer.

What is a proof of concept?

A proof of concept is an experiment that shows an idea is feasible. The proof of concept meaning in software is narrow. It is not a product and it is not meant to look finished. It is the smallest piece of working code that settles a risky question, such as whether a model can pull the fields you need from your documents, or whether you can read and write data in another company’s system.

Three things set it apart:

• One question. It tests a single risk and nothing else.
• Real code, no polish. It has to run, but it usually has no finished screens, no proper security and little error handling.
• Built to be thrown away. The GOV.UK Service Manual tells teams in its alpha phase to expect to throw away code at the end, and that the code is not production quality. The same attitude suits a proof of concept.

Feasibility questions are often about access rather than code. On our SBU sales automation project, the client’s Salesforce edition did not include API access as standard, and access was negotiated on the existing plan, so no tier upgrade was needed. That is the kind of fact you want before you budget a build. For AI ideas the equivalent question is whether a model can do the task on your real data, which only an experiment can answer.

Write the question down as a yes-or-no before you start, and agree what result counts as a yes. Without that pass mark, a proof of concept drifts into an open-ended build that nobody can call finished.

If the technology is well understood, skip the proof of concept and spend the money on the next stage.

What is a prototype?

A prototype is a version of the product you can look at and use, without the real system behind it. For most digital products that means a clickable prototype in a design tool such as Figma. Every key screen is designed, and the taps and links behave like the finished product, so people can try the journey on a real device. Its question is whether people will understand it and want it.

The word is stretched in software. GOV.UK’s alpha phase involves building prototypes and testing different ideas, and that can include working code as well as screens. We use “prototype” for the designed, clickable kind, the output of UX and UI design work.

Because nothing real sits behind the screens, a prototype cannot take payments, hold real data or run for real customers. What it does well is cheap change. Moving a button in a design file costs far less than changing it in code, so you can put the idea in front of users, and investors, before you fund the build.

Test a prototype by giving people a task and watching them attempt it without help. Where they hesitate or tap the wrong thing is the finding, and it is far cheaper to learn it from a design file than from a live product.

That is how it worked on Fix My House, a marketplace connecting homeowners and tradespeople. We delivered a high-fidelity interactive Figma prototype in weeks, so the founder could validate the idea with users and investors before funding development.

Some prototypes have to run on the real device. Our NicheCom project is a prototype only: a native iPad app for property floorplans, built around laser-measuring hardware.

What is an MVP in software development?

MVP stands for minimum viable product. It is a real product, live with real users, that has only the features needed to test your main assumption. Eric Ries defined it in a 2009 post as the version of a new product that lets a team collect the maximum validated learning about customers with the least effort. The Lean Startup site describes the point of an MVP as starting the process of learning as quickly as possible.

“Minimum” describes the features, not the quality. What exists has to work well enough for real people to use it, and for you to learn from what they do.

To choose the features, list what a user must be able to do to get the value you are promising, and cut everything else. Admin extras, secondary screens and nice-to-have settings can wait until real use has earned them a place.

A quick test separates an MVP from a prototype. Could a stranger use it today, with real data, without you in the room? If yes, it is an MVP. If not, it is still a prototype.

Our published prices for MVP development are validate & design (2–4 weeks) from £5,000, and an MVP build from £15,000, live in around three months.

Simple PT shows what lean looks like. The founder came to us on a tight budget. We planned the build in stages and shipped a deliberately lean MVP, and a working booking-and-payments app was live on both app stores two months from kick-off.

PoC vs prototype vs MVP: the differences at a glance

The three differ in the question they answer and what you are left holding. The table adds the discovery sprint, because it is the stage that decides which of the others you need.

Stage	The question it answers	What you get	Time and price with us
Discovery sprint	Which problem is worth solving, and what should we build first?	A validated, costed product plan	1–2 weeks, from £4,000
Proof of concept	Can this be built, or will this technology do the job?	Working code for one risky part, usually thrown away	No separate published price. The nearest published stage is the discovery sprint
Prototype	Will people understand it and want to use it?	A designed, clickable version with nothing real behind it	Validate & design (2–4 weeks) from £5,000. Discovery through to a clickable prototype from £8,000
MVP	Will real people use it, and keep using it?	A live, working product with only the features that test your main assumption	MVP build from £15,000, live in around three months

Every price above is a starting price. Scope and price are fixed and agreed before work starts, and the price rises with the number of user types, integrations and regulated workflows involved. For what a full build costs once you get past the MVP, see how much an app costs in the UK and software development cost in the UK.

Be careful with labels when you compare quotes. The three words are used loosely, so ask what you will have in your hands at the end and who could use it.

What is the discovery phase?

Discovery is the stage before anything is built. The GOV.UK Service Manual puts it simply. Before you commit to building a service, you need to understand the problem that needs to be solved. For government services it says around 4 to 8 weeks is typical, and that the purpose of the discovery should set how long you spend on it.

The manual then describes the stages that follow. In alpha, which tends to last 6 to 8 weeks, teams build prototypes and test different ideas. In beta, they take the best idea and start building it for real. The shape is the same in a commercial product: find out what is worth doing, test the risky parts cheaply, then build.

Those timings come from public-sector services. Ours is a smaller unit of work. A discovery sprint takes 1–2 weeks and starts from £4,000, and extending it to a clickable prototype starts from £8,000. A good discovery ends with a decision. Build it, build something smaller, test it with a prototype first, or do not build it at all. That decision is what the product discovery service is for.

Which should you build first?

Start from your riskiest assumption. The GOV.UK alpha guidance makes the same point, telling teams to focus on testing their riskiest assumptions. Work out which kind of doubt is biggest, then buy the stage that removes it.

• You are unsure it can be built. New technology, a hard integration, data you have not seen yet. Run a proof of concept.
• You are unsure people will understand it, or that an investor will back it. Build a prototype.
• You are confident it can be built and understood, but not that people will use it. Build an MVP.
• You cannot say which of these is the risk. Start with a discovery sprint.

You do not need all three. Each stage you skip is a stage you do not pay for, so the aim is to buy the cheapest test that answers your biggest doubt. For many products the sensible path is discovery, then a prototype, then an MVP, and a proof of concept joins the list only when feasibility is the real doubt.

Whichever stage you commission, the work is yours once it is delivered and paid for, so you can take a prototype or a proof of concept to another supplier or an investor.

Three mix-ups are worth avoiding:

• Treating a proof of concept as version one. It was written to answer a question, so building the product on top of it usually means rewriting it.
• Calling a clickable prototype an MVP. It cannot take real customers, and anyone you pitch to will ask how many are using it.
• Overbuilding the MVP. Every extra feature delays the moment you start learning, which is why Simple PT’s build was planned in stages and kept lean.

Your next step

If you are deciding what to fund first, send us the idea and the assumption you are least sure about. A discovery sprint, from £4,000 over 1–2 weeks, gives you a validated, costed product plan and tells you which of these stages is worth paying for. Scope and price are fixed before work starts, and you can cancel within the first 21 days and get your money back in full.

If you already know a working product is the next step, the MVP build starts from £15,000. Once you know what to build, our guide to web app vs website vs native app covers the platform decision.