Prototype, proof of concept, pilot, minimum viable product, spike, demo, and sandbox name seven instruments for producing evidence about a system before an organisation commits to it. They are not seven stages of one sequence, and they are not seven mutually exclusive kinds of project — which is what almost every argument about them assumes.
The seven words are drawn from four independent dimensions of the same piece of work. That is why they overlap, why two of them can correctly describe one project at once, and why no ordering rule between them holds.
Four dimensions
Every piece of pre-commitment work has four properties, and they vary independently of each other.
The question. What uncertainty the work exists to resolve.
The artifact. What gets built, at what fidelity, and what is kept afterwards.
The exposure. Who encounters the result, and whether anything real depends on the output.
The environment. What the work is permitted to reach — which networks, files, identities, data, and tools.
Five of the seven labels name a question. Demo names an exposure: it is a form of communication, not a stage of maturity. Sandbox names an environment. This is the entire source of the confusion. “Is this a prototype or a pilot?” and “is this a demo?” interrogate different axes, and both can be answered yes about the same afternoon’s work.
What each instrument settles
Each instrument settles one thing and leaves everything else untested. The part it leaves untested is the untested remainder, and the label conceals it. An instrument is chosen well when its remainder is something the organisation can afford not to know yet.
A prototype is a partial build that shows what a system would be like. It answers what would this be? and returns a description of behaviour or design. Fidelity is not part of the definition: a paper sketch and a working interactive build are both prototypes, and prototypes appear late in a programme as readily as early. Remainder: recovery, workload, integration, and ownership — everything the selected aspects did not touch.
A proof of concept tests whether a specific capability is achievable under stated conditions. It answers can this work at all? and returns a yes or a no. Remainder: behaviour outside the tested conditions, and the whole question of whether anyone will use it.
A pilot runs a bounded implementation in real conditions to inform a decision about wider rollout. It answers does this hold up in use? Remainder: the workload the cohort never carried, and who will own the result afterwards.
A minimum viable product, or MVP, is the smallest release that tests a hypothesis about a product. It answers does anyone want this? This is the one label whose definition is genuinely contested: one tradition selects for validated customer learning, another for the smallest increment of stakeholder value, and both are in live professional use. The remainder is identical either way. Remainder: the deployment and operating case, which no product hypothesis addresses.
A spike is a timeboxed investigation that unblocks a delivery decision. It answers which way do we build it? Nothing restricts a spike to code, and no duration is fixed by the term. Remainder: a maintained implementation, if the answer turns out to need one.
A demo is a presentation of selected system behaviour to an audience. It answers no question by itself. Its evidential value comes entirely from the declared task, conditions, and observations that accompany it — not from the polish of the presentation, and not from nothing. Remainder: a test protocol, without which no performance claim survives the room.
A sandbox is an environment with stated limits on execution and resource access. It also answers no question. It constrains what the work inside it can reach. Remainder: whether those limits are tested rather than asserted, and everything about the system running inside them.
Five of these settle a question. Demo and sandbox settle none, which is why the seven cannot be arranged into a sequence.
The rule
What stays fixed is the four dimensions: every piece of pre-commitment work has a question, an artifact, an exposure, and an environment, whether or not anyone wrote them down. What changes between instruments is which single dimension the label fixes, and how large a remainder it leaves unstated.
So a label authorises nothing. Expenditure, customer exposure, and transfer each require the specific evidence they require, and no instrument name supplies it. The practical move is to stop asking what a piece of work is called and ask the four questions directly. They can be answered about any project in a few minutes, they produce the same answers regardless of what the deck says, and they expose the remainder that the label was hiding.
Where the labels fail
Two failures, from different causes.
One programme, two labels. On 11 November 2024, the UK Department for Science, Innovation and Technology published the projects under its Rural Connectivity Accelerator programme. The announcement calls the planned viability tests pilots and says they will provide proof of concept: one issuer, one document, one programme, two of the seven labels. This is not a drafting error. It is evidence that the labels do not partition the space. Any governance process that routes work differently depending on which of those two words reaches the form is routing on noise.
One word, two definitions. In security usage, a sandbox is an execution environment with restricted resource access. In financial regulation, the Financial Conduct Authority’s Regulatory Sandbox is live market testing with real consumers. “We ran it in a sandbox” therefore means either isolated from everything or live with real customers and real money. The failure here is not overlap between neighbouring labels but a single word carrying incompatible meanings across domains, and it is the collision that bears directly on access control. Participation in a named programme is not an access review.
Not to be confused with
Readiness levels. Maturity scales such as NASA’s Technology Readiness Levels run from concept to flight-proven, and prototype and demonstration language appears inside those scales at several levels. The seven instruments are not themselves a scale and do not map onto one.
Contract definitions. These words carry specific agreed meanings in procurement documents and statements of work, and there the agreed meaning governs. Read the definitions clause before applying any of this to a contract.
A delivery sequence. A team can demonstrate a prototype running in a sandbox, and run a spike to settle an interface question in the middle of a pilot. Those labels are compatible because they name different axes. No order between them is required.