Build a proof of concept when the main unknown is technical feasibility. Build a prototype when the main unknown is interaction, flow or usability. Build an MVP when the main unknown is real customer behaviour, demand, willingness to pay or repeat use.

They are not a compulsory sequence. Choose the smallest artefact that can produce evidence for the riskiest unresolved assumption. If that assumption dies, stop. If it survives, fund the next piece of evidence. Do not fund ceremony.

If you do not yet know which risk matters most, start with product design for discovery and prototypes. If demand is the remaining risk and scope is ready, SaaS platforms is the working-product route. Once the cut is clear, the MVP build time guide covers the calendar.

PoC vs prototype vs MVP at a glance

Artefact	Question it tests	Typical audience	What is real	Evidence it can produce	What it cannot prove
Proof of concept	Can this risky technical path work in the relevant environment?	Engineers, technical stakeholders	A narrow technical experiment. Often throwaway.	Feasibility on a named integration, data path, model, performance target or architecture choice	That people understand the product, will buy it, or will keep using it
Prototype	Can people understand and complete the important interaction?	Designers, product owners, representative users, stakeholders	A design exploration. May be a sketch, clickable flow or code prototype	Clarity of the flow, usability friction, shared understanding of the intended experience	That the system is secure, scalable, connected to production data, or ready to ship
MVP	Will real customers behave in a way that supports viability?	Paying or pilot customers in a real context	An actual product or service that delivers the outcome	Sign-up, use of the primary workflow, payment, return use, support load, operational reality	That every future feature will work, or that a demo alone was enough

The Agile Alliance MVP glossary stresses validated learning about customers. An MVP is an actual product or service offered so behaviour can be observed. It may look more automated than it is. The common pitfall is treating “MVP” as the smallest feature list without enough viability to learn about demand.

GOV.UK guidance on making prototypes treats prototypes as a way to explore, share and test designs before production commitment. They range from sketches to code prototypes. Prototype code need not meet production security or performance standards, and it should not simply be copied into production.

When a proof of concept is the right first spend

Use a PoC when the riskiest unknown is technical. Examples of the kind of question it answers:

Can a document-extraction model reach usable accuracy on the buyer’s actual document set?
Can two systems exchange the required data without a brittle manual bridge?
Can a performance or architecture constraint hold under a realistic load sample?

A PoC can be throwaway. Its job is a go, change or stop call on feasibility. AWS Prescriptive Guidance describes that pattern for generative-AI work as testing technical feasibility in the relevant environment before a wider commitment. That page is AI-specific. Treat it as a useful principle for risky technical spikes, not as a universal formal definition of every software PoC.

A successful PoC does not mean customers understand the product. It does not mean they will pay. If usability or demand is still the open risk, fund that test next. Do not stretch a technical spike into a fake product launch.

Evidence worth collecting: pass or fail against a written feasibility threshold, notes on environment constraints, residual risks, and a clear recommendation to proceed, reshape or stop.

Exit when: the technical path works well enough to plan the next evidence step, or the evidence rejects the assumption and you stop or change the approach.

When a prototype is the right first spend

Use a prototype when the riskiest unknown is interaction, flow or usability. A useful example: can a customer understand and complete a complex quote flow without a salesperson walking them through every step?

Prototypes can be low or high fidelity. For fidelity choice, use the existing guide on low-fidelity vs high-fidelity prototypes. Keep this page on the funding decision, not the fidelity taxonomy.

GOV.UK’s alpha-phase guidance is clear on scope: test the riskiest assumptions with only enough prototype to learn. Not every journey must be prototyped. Alpha code is not production quality and may be thrown away.

A prototype may feel realistic. That does not make it secure, scalable, wired to production data, or an MVP. Do not ship prototype code because it looked convincing in a demo. Do not call a clickable demo an MVP if it cannot deliver the customer outcome.

Evidence worth collecting: task completion on the target journeys, where people hesitate or fail, stakeholder alignment on the intended experience, and a short list of changes required before any build.

Exit when: the important journeys are clear enough to scope a build, or the evidence shows the concept is confusing enough that you should reshape or stop before engineering spend.

Already vibe-coded the idea? Bring that as the brief

Many founders now arrive with a working artefact built in Lovable, Bolt, Replit, v0 or a similar prompt-to-app tool. That is normal. A runnable flow often communicates priorities, language and the founder’s product mental model better than a deck or a feature list.

We like receiving briefs this way. Walking through something tangible lets us challenge assumptions earlier, improve the product decisions and move towards a stronger first release. Bring the artefact. Do not apologise for it.

Classify it by what it actually does, not by how polished the screens look. It is still a prototype if it demonstrates interaction but cannot deliver the outcome to real users. It may already be an MVP if real users can complete the core job and produce meaningful behavioural evidence.

A convincing interface does not by itself prove secure authentication, correct permissions, safe data handling, maintainability, accessibility, performance, reliable integrations, operational cost or production readiness. Treat those as open questions until they are checked.

Handover is practical:

Understand the intended customer outcome.
Separate actual user evidence from assumptions.
Audit the repository, dependencies, auth, data handling and secrets.
Challenge the product and technical choices that matter for the first release.
Decide explicitly what to retain, what to refactor and what to rebuild.
Define and harden that first production release.

Generated code is not automatically bad, and we do not rebuild from scratch by default. Retain what is sound. Refactor what needs structure. Rebuild only where the risk or the gap justifies it.

Simon Willison draws a precise line between vibe coding (building with an LLM without reviewing the code) and responsible AI-assisted programming. Use that distinction when you decide how much of the artefact to trust in production. Our founder’s guide to vibe coding covers the tools, benefits and handover in detail, while vibe coding vs orchestrated AI engineering explains what changes when the prototype has to become a dependable product.

When an MVP is the right first spend

Use an MVP when the riskiest unknowns are real behaviour, demand, willingness to pay or repeat use. A useful example: will a real cohort sign up, complete the primary workflow, pay or return?

An MVP must be viable enough that the behaviour is meaningful. Manual work behind the scenes is allowed when customers still receive the outcome. A clickable prototype that cannot deliver that outcome is not an MVP, however polished the screens look.

The Agile Alliance framing matters here: the point is learning from customer behaviour, not completing a feature checklist. If you cannot observe meaningful behaviour, you do not yet have an MVP.

For timeline shape once scope is locked, see how long an MVP takes to build. That article shows 4, 8 and 12-week scope examples. The current public Custom SaaS MVP / Web App band is 6 to 10 weeks; the actual calendar is confirmed against agreed scope before Build.

Evidence worth collecting: activation into the primary workflow, completion of the job the product claims to do, payment or signed pilot commitment, return use over a defined window, support burden, and qualitative reasons for drop-off.

Exit when: the cohort behaviour supports a wider build or commercial next step, or the evidence rejects the demand assumption and you stop or reshape before more surface area is funded.

Combine artefacts when the risks stack. Skip them when they do not.

You can combine artefacts without turning them into a conveyor belt:

A narrow technical spike inside a Discovery Sprint when feasibility is still open.
A prototype before or alongside a tightly scoped MVP when the interaction is uncertain but you also need live behaviour soon.
A manual service behind a real MVP interaction when the customer outcome matters more than early automation.

You can also skip an artefact. Skip a PoC when the technical path is already proven in the relevant environment. Skip a prototype when the interaction is already validated with the people who will use it. Skip an MVP when you still lack a credible answer on feasibility or usability and a smaller test would teach you faster.

Progress is an evidence decision. If the evidence rejects the assumption, stopping is progress. Continuing through PoC, prototype and MVP because “that is the process” is wasted spend.

Workshop mechanics belong in what happens in a product discovery workshop. Use that article for the room, agenda and outputs. Use this one for which artefact to fund.

Current Code23 bands for discovery and MVPs

Current public project bands from pricing:

Discovery Sprint: £750 to £1,500, typically 1 to 2 weeks. Public scope: interactive prototype, system architecture, database schema, and a fixed-price build proposal, with 100% credited toward the build if you continue.
Custom SaaS MVP / Web App: £18,000 to £40,000, typically 6 to 10 weeks. Public scope includes auth, role-based access (RBAC), Stripe billing, customer dashboards, API endpoints, automated tests and a 90-day warranty.

Final price and timeline depend on agreed scope and are confirmed before Build. A Discovery Sprint is a discovery and prototype entry point. It does not promise a full PoC, a full user-research programme, or a production-ready prototype in every engagement. The SaaS MVP band is for a working release with enough viability to learn from real use. Not every founder should buy that band first. If the riskiest assumption still needs a smaller test, start smaller.

Sources

Next step

If you do not yet know which assumption is riskiest, start with product design and a Discovery Sprint. That is the entry point for framing the risk, shaping a prototype and deciding whether a build is justified. If the evidence and scope are ready for a working release, go to SaaS platforms and scope the MVP cut before Build.