A proof of concept is a small build whose only job is to answer one question: is this technically possible? It is not a prototype, which shows how something will look and feel, and not an MVP, which ships to real users. Textbooks say you throw a proof of concept away — but at Spotify, a six-week proof of concept became Backstage, now a public open-source project. Here is what a PoC proves, how it differs from the alternatives, and what actually happens to the code.

Proof of concept vs prototype vs MVP

Each of the three answers a different question. Choosing the wrong one wastes weeks.

The sequence is not mandatory. Plenty of teams go straight from a proof of concept to production, and plenty skip the PoC entirely because feasibility was never in doubt.

Where the definitions disagree

The three terms are not defined consistently across the industry, and the disagreement is sharpest around MVP. This matters more than it sounds, because two people using the same word to mean different things will plan different work.

Atlassian and SVPG are saying incompatible things. One treats the MVP as a shipped product; the other insists it should not be a product.

Proof of concept is less contested. The common thread across sources is that a PoC exists to reduce risk before investment. AWS frames it well: a proof of concept should not be an impressive demo but a rigorous experiment that validates business value, data readiness, technical feasibility and delivery risk.

Practical advice: before starting, write down which definition your team is using. The argument is cheaper before the work than after it.

Proof of concept meaning and definition

A proof of concept is a deliberately small piece of work built to test whether an idea is feasible, before committing budget to it.

Three properties distinguish it from ordinary development work:

It has exactly one question. Not "is this a good idea" but "can our data model support this query volume" or "can this library parse our file format". A PoC with three questions is a project.

It has a deadline that is short enough to be uncomfortable. Days or a few weeks. The discomfort is the point — it forces you to build only the risky part.

It has a defined failure condition. If you cannot say in advance what result would make you abandon the idea, you are not running an experiment, you are building a demo.

Proof of concept in software development: what teams actually test

In software, PoCs cluster around a handful of recurring questions.

Technical feasibility. Can this integration work at all? Does the third-party API expose what we need? If the risky part is an API or service boundary, treat the PoC like focused web service testing: test the contract, failure modes and data you actually depend on.

Performance at scale. The system works with a hundred records. Does it work with ten million?

Tooling fit. Will this framework handle our authentication, our dynamic elements, our pipeline?

Data readiness. Do we actually have the data this feature assumes, in the quality it assumes? Teams that already have a test data management process have an advantage here because they can build the experiment around realistic data instead of a hand-cleaned sample.

The last one is the most commonly skipped and the most commonly fatal. Features are abandoned mid-build over data problems that a two-day PoC would have surfaced.

5 real proof of concept examples

Most articles about proofs of concept ask you to imagine building an app. These are documented cases with named companies, and where a duration is not stated publicly we say so rather than estimate.

Spotify: an infrastructure graph in one day

Question: could a graph approach turn a cloud asset inventory into a usable dependency map?

During a Hack Day, a Spotify team built a proof of concept that produced a graph from a subset of their asset inventory. Duration: one day. Outcome: a working graph over part of the inventory, enough to justify continuing. What happened to the code afterwards is not stated in the write-up.

Source: Spotify Engineering

Spotify: Backstage, six weeks from PoC to open source

Question: could Spotify's internal developer portal be turned into an external product?

A small team started building a proof of concept during a Hack Week. Six weeks later, Backstage was publicly released as open source. It is now one of Spotify's largest open-source projects.

This is the clearest counterexample to the textbook rule that a PoC gets thrown away.

Source: Spotify Engineering

Spotify: deep linking, 79% fewer broken links

Question: would an alternative deep-linking approach fix long-standing attribution problems?

Spotify entered a short-term contract specifically to test a proof of concept. In 2021 the results showed a 79% reduction in broken links, which led to an approved enterprise-wide migration involving at least 25 internal stakeholder teams plus external partners. Duration: not stated.

Source: Spotify Engineering

Spotify: event delivery, from PoC to production

Question: would new components handle Spotify's event delivery load?

Components were first hacked together as a proof of concept, then developed into a more mature prototype that could be used in production. Internal users were onboarded early, then traffic was scaled up. Duration: not stated.

This is the PoC → prototype → production path in a single project.

Source: Spotify Engineering

Dropbox: Magic Pocket

Question: what do our real workloads and file distributions actually look like?

Before committing to a major infrastructure initiative, Dropbox built a small prototype as a proof of concept to understand workloads and file distributions, then iterated toward a production implementation. Duration: not stated.

Source: Dropbox Tech

How to run a proof of concept, step by step

Define the one question

Write it as a sentence that can be answered yes or no. "Can Postgres full-text search return results in under 200ms across our 40 million documents?" — not "should we use Postgres for search".

Set a time box before you start

Pick the duration first, then decide what fits inside it. Doing this in the other order produces a project.

Define what "proven" means, and what "failed" means

Both. A PoC with only a success condition will always succeed, because someone will find a way to declare it so.

Decide upfront what happens to the code

This is the step almost every template omits, and the one that causes the most damage. Agree in advance whether the code is deleted, kept as a reference, or promoted — and who decides.

Build only the risky part

No authentication unless authentication is the question. No UI unless the UI is the question. Every hour spent on the parts you already know how to build is an hour not spent reducing risk.

Write down the answer

A PoC that ends in a conversation rather than a document will be re-run in nine months by someone who was not in the room.

Proof of concept document and template

Templates for proofs of concept are widely available — Smartsheet offers a one-pager, a report and a checklist, and AWS publishes a POC playbook for Redshift that recommends starting from business requirements, measurable success criteria and a minimal dataset.

Most of them share a gap: none says what to do with the code. This structure closes it.

A good proof of concept document is short enough to read before a decision meeting. It should preserve the question, conditions, measured result and limitations. The code can be temporary; the evidence should not be.

1. Question or hypothesis      one sentence, answerable yes or no
2. Scope and non-scope         what you will build, what you will not
3. Success criteria            the result that means yes
4. Failure criteria            the result that means stop
5. Risks and assumptions       what could invalidate the answer
6. Setup and data              environment, dataset, access needed
7. The experiment              what was actually built and run
8. Results                     measured, not summarised
9. Gaps to production          what would still need building
10. What happens to the code   delete, archive, or promote — and who decides
11. Go / no-go                 the decision and who made it

Items 4 and 10 are the ones worth defending when someone tries to trim the template.

What happens to the proof of concept code?

Textbook answer: you throw it away. That is what "throwaway" in the definition means.

Real answer: often you do not — and four of the five examples above show why. Backstage became a public product. The Spotify event delivery components were matured into production. Dropbox's Magic Pocket prototype was iterated rather than discarded.

This creates a specific, common failure: code written to answer a question, with no error handling, no tests and no security review, ends up in production because it worked and the deadline moved.

Three practical positions, decided in advance:

Delete it. Cleanest. The knowledge lives in the write-up, and the production version is built properly.

Archive it as a reference. The repository is marked read-only and never imported. Reasonable middle ground.

Promote it deliberately. Legitimate, but it stops being a PoC at that moment and needs everything you skipped — tests, error handling, review. Budget that time explicitly rather than discovering it later.

The failure mode is not choosing any of the three, and letting the decision be made by whoever is closest to a deadline.

Proof of concept testing: how to validate a PoC

A proof of concept does not need a full test suite — that would defeat the purpose. It needs enough verification to make the answer trustworthy.

Test the claim, not the code. If the question is about performance under load, the only test that matters measures performance under load, with data that resembles production in shape and volume. Think of it as validation testing with a deliberately narrow target: you are validating the risky assumption, not the whole product.

Use realistic data. A PoC validated on clean synthetic data answers a question nobody asked.

Record the conditions. Machine, dataset size, configuration, versions. A result nobody can reproduce is an anecdote. If several runs or environments are involved, keep the evidence in the same place you use for test reporting so the final go/no-go decision can be traced back to the actual result.

Test the failure path too. What happens when the API is unavailable, the file is malformed, the dataset is twice as large? Feasibility that only holds in the happy path is not feasibility.

Teams also run proofs of concept on tooling, not just on features — a two-week trial to answer whether a testing tool fits the stack. The question there is narrow: can it handle our login, our dynamic elements, our CI setup? Free tiers exist precisely so this can be answered before a purchase order.

If the tool PoC is about test automation specifically, our guide to test automation tools covers what to evaluate, and the test plan template gives you a structure for recording the results.

When a PoC is a waste of time

When feasibility was never in question. If three teams in your company have already built this, you need their write-up, not your own experiment.

When the real question is commercial. "Will customers pay for this" is not answered by a technical PoC. That is a research or pricing question.

When there is no failure condition. A PoC that cannot fail is a demo with a serious name.

When the time box is longer than a month. At that length, you are building the thing. Either accept that and plan it properly, or narrow the question.

When nobody will read the result. If the decision is already made, the PoC is theatre — and expensive theatre, because it consumes engineering time to produce a conclusion nobody is waiting for.