Proof of concept (PoC)
A proof of concept is a deliberately throwaway experiment built to establish whether a specific technical approach can work at all. It is tested by the team rather than by customers, answers one feasibility question, and is expected to be discarded once that question has an answer.
Also known as: PoC, Proof of principle, Feasibility study, Technical spike
Last reviewed
Why a proof of concept matters
Some risks are technical rather than commercial. Can this legacy system actually be read? Will the model be accurate enough on our real data? Can this run fast enough at the volume we need? Those questions cannot be answered by discussion, and getting them wrong late is expensive, because by then an architecture has been built on the assumption.
A proof of concept isolates one such question and answers it for a small, bounded cost. Because it will be thrown away, it can ignore everything that normally consumes project time: no design, no permissions, no error handling, no tests beyond the point being proved.
How a proof of concept works
Start by writing the question as something that can be true or false, with a threshold — not "can we use AI on this", but "can this extract the invoice total correctly on 95 of 100 real documents". Then build the least code that settles it, using real data wherever possible. Synthetic data is the most common way a PoC produces a reassuring and useless answer.
The output is a decision and a short write-up, not a codebase. Keeping the code in order to "build on it later" is how a throwaway experiment becomes the foundation of a production system, which is a reliable source of technical debt.
Proof of concept vs MVP
A PoC asks whether something can be built; an MVP asks whether anyone wants it. A PoC is used internally and discarded; an MVP goes to real users and is kept and extended.
The mistake that costs most is treating one as the other. Showing a PoC to customers oversells something that has no error handling. Treating an MVP as disposable means throwing away code you now depend on. When a project needs both, the PoC comes first and should take a fraction of the time.
When you need one
Commission a proof of concept when a single technical unknown would change the whole plan: an integration nobody has attempted, a performance ceiling, or an AI capability whose accuracy on your data is genuinely unknown. Where the unknown is commercial rather than technical, skip it — an MVP or a conversation with ten prospective users is the cheaper test.
Set the time limit and the pass mark before you start. A proof of concept with neither tends to keep going until it has quietly acquired features, at which point it is an unplanned build rather than an experiment.
Proof of concept: common questions
A proof of concept tests whether something can technically work and is judged by the team. A prototype tests whether people understand and want the thing, and is judged by users. A proof of concept is usually ugly and functional; a prototype is usually attractive and non-functional.
Generally no, and planning to keep it changes how it gets built, which defeats the purpose. Its value is the answer it produced, not the code. Reusing a deliberately unfinished experiment as a production foundation is one of the most common sources of technical debt we encounter.
Far less time than a build, because almost everything is excluded. The discipline is to fix the question, the threshold and a time limit before starting. If a proof of concept is running for months, it has usually acquired features and stopped being an experiment.
Want to talk about your project?
Tell us what you’re trying to achieve and we’ll map the fastest credible path.