A proof of concept is a small, time-boxed experiment that tests whether one risky idea will actually work, before an organisation commits to a full software build. It is not a finished product and is not for real users: it answers a single focused question and produces a go or no-go decision.
What a proof of concept is for
A proof of concept exists to remove doubt cheaply. Every bespoke software project carries some uncertainty, and now and then a project rests on one assumption that nobody can be sure of: a new technology, a tricky data source, a third-party system that may or may not behave as hoped. A proof of concept tests that single assumption on its own, before the budget for a full build is at stake.
The general technology reference Wikipedia's article on proof of concept describes it as a demonstration whose purpose is to verify that a concept or theory has practical potential. In a software project that means a deliberately rough experiment, built only to answer the question and then set aside.
The outcome is a decision, not a deliverable. A proof of concept ends with a clear answer: yes, this works and the project can proceed, or no, it does not, and we should change the approach or stop. Spending a little to learn that early is far cheaper than discovering it halfway through a full build.
When you should ask for one
A proof of concept is not a routine step in every project. It earns its cost only when a specific part of the work carries genuine technical risk. As a buyer, it is worth asking your software partner for one when:
- An unproven technology is involved. The project depends on a tool, platform or technique your team has not used before, and no one can promise it will do what you need.
- A risky integration is on the critical path. Your new system must connect to an old, poorly documented or external system, and the whole project fails if that link cannot be made to work.
- The context is regulated or high-stakes. You are working in a regulated sector, or the cost of getting it wrong is severe, so an early evidenced check is prudent before a larger commitment.
If none of those apply and the project uses well-established methods, you can usually skip the proof of concept and move straight into design and build. The honest answer is that most small projects do not need one.
What good success criteria look like
A proof of concept is only useful if everyone agrees, before it starts, what would count as success. Vague aims such as "see if it works" lead to vague results that no one can act on. Good success criteria are agreed up front and written down.
A clear brief sets out four things: the single question being answered, the specific result that counts as a pass, the time and budget allowed (this is the "time-boxed" part) and what happens at each outcome.
For example: "Can we pull live stock data from the supplier's system and display it within five seconds? We have eight working days. If yes, the project proceeds; if no, we review alternative suppliers."
Writing criteria this sharply protects you. It keeps the experiment small, stops it quietly turning into the real build and means the go or no-go decision is based on evidence rather than opinion.
Proof of concept vs prototype vs MVP
These three terms are often used loosely, but they answer different questions at different stages of a project, and confusing them leads to spending money on the wrong thing.
- Proof of concept answers "can this idea work at all?" It is an internal experiment, usually rough and throwaway, focused on technical feasibility. No real users see it.
- Prototype answers "how should this look and feel?" Once feasibility is settled, a prototype tests the design, layout and user experience. It looks more like the real thing but the workings behind it are not real. See our entry on wireframes, mockups and prototypes for how these design artefacts fit together.
- Minimum viable product (MVP) answers "do people actually want this?" An MVP is a small but genuinely working product released to real users, so you can learn from how they use it. Our UK guide to MVP development covers this in depth.
A simple way to remember the order: a proof of concept proves it can be built, a prototype shows how it should feel and an MVP tests whether customers want it. The UK government's Service Manual describes a similar progression through its discovery and alpha phases, where teams test risky ideas and build throwaway versions before committing to a full service. A proof of concept is one tool in the wider software development lifecycle, used most often during early discovery work.
Not sure whether your project needs one? A good software partner will tell you honestly when a proof of concept is worth the cost and when it is not. Our bespoke software development team de-risks the uncertain parts of a project first, so you commit to a full build with evidence behind you rather than a hopeful guess.
