Getting the vocabulary right before you brief a vendor or pitch an investor has real financial consequences. In our custom software development engagements, wrong artefact choice is one of the top three scoping errors that cause budget overruns — typically surfacing in month three when an “MVP” turns out to be a prototype-grade build that needs a full rebuild from scratch.
MVP vs prototype vs proof of concept: what is the difference?
Short answer: a proof of concept asks “can we build it?” ($5–25k, 1–3 weeks, internal-only). A prototype asks “do users want it?” ($5–15k, 1–2 weeks, no real backend). An MVP asks “will they pay for it?” ($30–400k, 6–14 weeks, a real revenue product). Match the artefact to the question before you spend a single sprint.
Three artefacts, three jobs:
- Proof of Concept (PoC) answers “can we build it?”. Internal-only, throwaway, technical. $5–25k. 1–3 weeks.
- Prototype answers “do users want it?”. External-facing, simulated, no real backend. $5–15k. 1–2 weeks.
- MVP answers “will they pay for it?”. Real product, real users, real money. $30–400k. 6–14 weeks.
Using the wrong word in a vendor brief is the most expensive linguistic mistake in early-stage software. A team that quotes you an “MVP” while you are still asking PoC-shaped questions will sell you 12 weeks of engineering when you needed two weeks of Figma. A team that quotes a “prototype” when you need a regulated MVP build will leave you with a clickable demo and no path to revenue.
Proof of Concept — what it actually is
A PoC is a focused technical spike. Its only job is to reduce a specific risk to a binary answer: yes this works or no it does not. It is internal, ugly, throwaway and almost never has a UI worth showing to a customer.
In 2026 the PoCs we run most often are:
- Retrieval quality benchmarks comparing Claude 4.6 Sonnet, GPT-4o and Gemini 2.5 Pro against the founder's own document corpus, using LlamaIndex or LangChain as the harness.
- Cost/latency probes — how does $/1M tokens map to actual unit economics when we hit the real query distribution? At $3 in / $15 out per 1M for Claude 4.6 Sonnet, $2.50 / $10 for GPT-4o, and $1.25 / $5 for Gemini 2.5 Pro, the choice often flips once we see real prompts.
- Agent feasibility spikes — can a tool-using agent actually complete the workflow end-to-end on 80% of cases with reasonable supervision? See AI agents development for the patterns we use in production.
- Integration spikes — will the third-party API (Plaid, Truelayer, Stripe Connect, HubSpot, NetSuite) actually expose the data we need in the shape we need?
| Attribute | Proof of Concept |
|---|---|
| Audience | Internal team, occasionally one technical investor |
| Code quality | Disposable. Jupyter notebooks, scripts, no tests, no auth |
| UI | None or Streamlit/Gradio |
| Cost (2026) | $5–25k |
| Timeline | 1–3 weeks |
| Success criterion | A measurable, written answer to one risk question |
Prototype — the user-facing experiment
A prototype is a simulation of the product, fast and cheap, used to test whether real users understand the flow, find the language clear, and respond to the value proposition. It is not the product. It does not need to actually work.
In 2026, prototypes split into three flavours:
- Clickable Figma — the workhorse. 1–2 weeks. Tested with 8–12 users via Maze or moderated interviews.
- No-code prototype — Bubble, Softr, FlutterFlow, Glide. Useful when the value comes from the data flow itself, not just the interface.
- AI-assisted prototype — v0.dev, Bolt, Lovable. Generates a working React app from a prompt. Excellent for getting a real-feeling shell in hours, dangerous when founders mistake it for production code.
A prototype is honest about what it is. It does not have user accounts, it does not bill, it does not retain data across sessions. Its job is to let a user walk through the value moment in 90 seconds and tell you whether the value is real.
MVP — the smallest shippable revenue product
An MVP is the smallest product that real customers can use to get real value and from which you can collect real money. It is production code, on production infrastructure, with auth, billing, observability and a privacy posture. It is not a demo.
The defining feature of an MVP is the minimum in “minimum viable”. Most MVPs that fail are over-scoped — they include the second, third and fourth thing the founder wants instead of brutally cutting to the one thing the customer will pay for.
A typical 2026 standard MVP in EU nearshore lands at €130–215k all-in across 10–14 weeks. We covered the numbers in detail in how much does an MVP cost in 2026. The defining infrastructure components are auth (Clerk, Auth0, Supabase Auth), billing (Stripe), observability (Sentry + a metrics layer like Datadog or Grafana Cloud), analytics (PostHog or Amplitude) and a launch-ready privacy/consent layer.
| Attribute | PoC | Prototype | MVP |
|---|---|---|---|
| Question answered | Can we build it? | Do users want it? | Will they pay for it? |
| Real users? | No | Test users (8–12) | Yes, paying |
| Real backend? | Maybe (the spike) | No or fake | Yes |
| Auth, billing, observability | None | None | All required |
| Cost (2026) | $5–25k | $5–15k | $30–400k |
| Timeline | 1–3 weeks | 1–2 weeks | 6–14 weeks |
| Throwaway? | Yes | Yes | No — v2 builds on it |
Decision matrix — which one do you need?
Start at the top. If any row applies, do the artefact in that row before moving down.
| If this is true… | Build this first |
|---|---|
| There is a specific technical risk (model accuracy, integration availability, latency, cost) and no one on the team knows the answer | PoC |
| You have a clear technical path but you are not sure users will navigate the flow or understand the value | Prototype |
| Prototype tested well with 8+ users and you need real revenue or real retention signal to raise the next round | MVP (lean) |
| You have signed letters of intent, paying pilot customers, or a regulated context that requires the real thing | MVP (standard or regulated) |
Three worked examples
Example 1: AI legal assistant for solo lawyers
Founder has a thesis: solo lawyers will pay $99/month for a Claude-powered drafting assistant trained on their own past briefs. Three risks: (1) does the retrieval actually return relevant clauses? (2) does the UX feel safe enough for legal work? (3) will lawyers pay subscription?
- PoC ($12k, 2 weeks) — LlamaIndex over 200 anonymised briefs, Claude 4.6 Sonnet as the generator, written success criterion: top-1 clause retrieval > 0.75 on 50 hand-labelled queries. Passes at 0.81.
- Prototype ($8k, 1.5 weeks) — Figma + a thin v0.dev shell wired to the PoC backend, tested with 10 solo lawyers. 7 of 10 understand the value in under 90 seconds.
- Lean MVP (€55k, 8 weeks) — auth, Stripe Billing, real document upload, audit log, basic admin. Launched to a 30-user waitlist; 14 paid within month one.
Total spend to validated paying-customer signal: about €75k. Sequenced correctly. A “just build the MVP” approach would have committed €180k+ before learning that retrieval needed reranking.
Example 2: B2B SaaS scheduling tool
Founder is a recovering ops lead at a logistics company; she already knows the pain and the willingness to pay. No technical risk, no novel UX. PoC and prototype are wasteful.
- Skip PoC entirely — the stack (Next.js, Postgres, Stripe) is solved.
- Skip prototype or compress it to a 3-day Figma to align team on UI, not to test the idea.
- Go straight to standard MVP (€130k, 11 weeks). See SaaS development.
Example 3: Regulated HealthTech companion
Clinical context. Partial product is not just embarrassing — it is non-compliant. No useful MVP exists below the regulatory floor.
- PoC ($18k) — HIPAA-aligned data-flow architecture review, integration spike with the EHR vendor.
- Prototype ($10k) — Figma tested with 6 clinicians.
- Regulated MVP (€360k, 18 weeks) — the minimum legally shippable product. See fractional CTO for the leadership layer.
Real startup validation examples: Dropbox, Facebook, Instagram, and Slack
The same sequencing logic plays out across the most successful products in tech. The artefacts differ; the principle is identical — match the artefact to the uncertainty you need to resolve before spending on the next stage.
Dropbox: PoC without code
Drew Houston could not build a working Dropbox fast enough to test whether anyone would want it. Instead of spending months on infrastructure, he recorded a three-minute demo video showing the product as if it already existed. The waitlist grew from 5,000 to 75,000 overnight. The PoC was a video, not code — and it answered the only question that mattered at that stage: is there real demand?
Facebook: prototype scoped to one campus
Zuckerberg shipped “Thefacebook” in February 2004 as a Harvard-only release — incomplete, unmonetised, limited to one university. The signal from 650 sign-ups in the first four hours justified expanding campus by campus before any production infrastructure existed. The prototype validated the social graph mechanic before the engineering investment was made.
Instagram: MVP pivot from Burbn
Kevin Systrom’s original MVP was Burbn, a location check-in app. Retention data from real paying users showed that the photo filter feature was the only thing people returned for. The team cut everything else and relaunched as Instagram. This is the canonical example of an MVP surfacing a pivot signal that no PoC or prototype could have revealed — it required real retention data from real users over real time.
Slack: MVP from an abandoned game
Stewart Butterfield’s team built a multiplayer game called Glitch. The game failed, but the internal communication tool they had built to coordinate development turned out to be genuinely useful. They productised that communication layer as Slack and launched to a closed beta. No PoC was needed — two years of internal usage constituted stronger validation than any synthetic test could provide.
The pattern across all four: Houston had a demand unknown → PoC. Zuckerberg had an engagement unknown → prototype. Systrom had a retention unknown → MVP. Butterfield already had retention data → straight to MVP. Each artefact choice was deliberate, not accidental.
Red flags and language abuse
- “We can do an MVP in 4 weeks for $15k.” They mean “prototype.” Or they mean “templated low-code build with no auth, no billing, no observability.” Neither is an MVP.
- “Let’s ship a PoC to your first 50 customers.” A PoC is internal. The moment it has external customers, it is an unmaintained MVP and you will pay 3× to rebuild it properly.
- “The prototype will become the production code.” Almost never true. A coded prototype optimised for speed of iteration has none of the discipline (tests, types, error handling, observability) that production needs.
- “We don’t need a PoC, our engineers know the stack.” Knowing the stack is not the same as knowing whether the specific model, dataset or third-party will behave as needed. PoCs exist precisely because experienced engineers know they don’t know.
- “Let’s skip the prototype, we already know what users want.” The single most expensive sentence in early-stage product. The week of prototype testing pays for itself ten times in the MVP build.
A sensible sequence for funded founders
If you are sitting on a fresh pre-seed or seed cheque and you want to spend it well, the canonical sequence we recommend is:
- Week 0–1: Discovery sprint. One senior product engineer + one designer + the founder. Decide whether you need a PoC, prototype, or both, in writing.
- Week 1–3: PoC if needed. Only if a specific technical risk is unknown. Skip otherwise.
- Week 2–4: Prototype. Figma + paid traffic to a landing page. 8–12 user tests.
- Week 4–5: Go/no-go decision. Document what you learned, kill or pivot if the prototype failed, scope the MVP if it passed.
- Week 5–19: Lean or standard MVP. 10–14 weeks, real product, real billing.
- Week 19+: Iterate based on real revenue. Not on opinions, not on roadmap, on revenue.
Total elapsed: about 5 months from cheque to revenue signal. Total spend: typically €160–230k for a B2B SaaS in EU nearshore. Total information value: enormous compared to skipping any of the steps.
When can you skip the PoC, prototype, or MVP?
The three artefacts are sequenced by logic, not by rule. Here is when each is safely skippable — and when skipping it is a mistake that founders pay for later.
Skipping the PoC
Safe when there is no novel technical risk. If your stack is React, Postgres and Stripe, and your team has shipped it dozens of times, a PoC adds no information — skip it. PoCs are only valuable when the specific technical question (model retrieval accuracy, integration data shape, p95 latency, cost per query) genuinely does not have a known answer before you start.
Skipping the prototype
Rarely advisable. The exception: you have shipped to this exact user profile before, and your confidence comes from years of direct observation, not from assumptions. The second exception: a B2B pilot where the paying customer co-designs the product weekly and provides direct UX feedback inside the contract. In both cases the prototype’s information value has already been captured elsewhere.
Skipping the MVP
Sometimes forced. In regulated healthcare, financial licensing and clinical contexts, a partial product can be legally non-compliant — the regulatory floor is effectively your MVP floor. You are not skipping the MVP; you are building to a higher minimum. The “minimum viable” discipline still applies within the constraint. This is why scoping regulated products correctly requires a fractional CTO from the discovery phase, not just an engineer.
The dangerous skip: prototype directly to production
The most common mistake we see is a founder productising a v0.dev, Bolt or Lovable build. The coded prototype was optimised for speed of iteration, not for security, observability or scale. Treating it as production code typically results in a full rewrite within 6–9 months at 3–4× the original cost. The tell: if your “MVP” has no auth, billing and error monitoring, it is a prototype in production — and the clock is ticking.
FAQ
What is the difference between an MVP, a prototype and a proof of concept?
PoC: can we build it? Prototype: do users want it? MVP: will they pay for it? Different audiences, different costs, different artefacts.
How much does a proof of concept cost in 2026?
$5–25k for 1–3 weeks with a senior engineer. The most common 2026 PoCs are RAG retrieval benchmarks, agent feasibility spikes, and cost/latency probes across the major frontier models.
Do I need a prototype before an MVP?
Almost always yes. A $5–10k clickable Figma surfaces wrong assumptions that would otherwise be paid for in 12 weeks of engineering.
When should I skip the MVP and go straight to v1?
Only with prior customer demand, a regulated context, or a paid enterprise pilot.
Can a no-code tool replace a prototype?
For testing flow and language — yes. The problem starts when you try to scale a no-code MVP past 1,000 paying users.
Who owns code from a PoC or prototype?
You should — negotiate full IP transfer in the SOW even for throwaway code. Many vendors silently retain rights.
Can a PoC be a video or wireframe instead of working code?
Yes. Dropbox’s original proof of concept was a three-minute demo video that grew the waitlist from 5,000 to 75,000 overnight — no working product existed. A PoC proves feasibility of a proposition to the team making the go/no-go decision; the format must match the specific uncertainty being resolved. If a landing page with a waitlist button answers the demand question, that is a valid PoC. If the uncertainty is retrieval accuracy in an LLM pipeline, you need working code with measurable output.
How do I write a measurable success criterion for a PoC?
Define the metric, the threshold, and the measurement protocol before the first commit: “Claude 4.6 Sonnet retrieval precision on 50 labelled queries must exceed 0.78 using LlamaIndex with a 3-chunk top-k window.” Three components: the variable (retrieval precision), the threshold (0.78), the measurement protocol (50 labelled queries, 3-chunk window). A PoC without a written criterion before it starts is not a PoC — it is a hobby project paid for with founder money.
What is the difference between a PoC and an Agile spike?
A spike is a time-boxed investigation inside a sprint: typically 1–4 days, produces a recommendation in the retrospective, consumed by the team immediately. A PoC is a standalone validation project: 1–3 weeks, produces a written deliverable (benchmark results, feasibility report, architecture decision record) that informs a formal go/no-go. Both are throwaway and internal-only; the difference is scope, duration and the formality of the output.
Get a discovery plan, not a vendor quote
Tell us what you are trying to learn. We will tell you which artefact (PoC, prototype, MVP) actually answers it — even if it means a smaller engagement.
Last updated 15 September 2026.
