When it is worth doing
Some decisions cannot be made on paper. Estimates and vendor claims will not settle those. Building the smallest thing that tests them will.
- The approach is unproven in your environment, and the cost of being wrong is high.
- Two or more options are on the table and nobody can argue the choice down on paper.
- A vendor or platform claim needs testing against your data, your load and your constraints.
- An integration with a legacy or third-party system is the main unknown.
- An AI or data feature depends on accuracy, latency or cost that nobody has measured.
- Funding, or a stakeholder, is waiting on evidence rather than an opinion.
How we run one
Turn the idea into a question
We work with you until the concept is a single question with a pass mark: not “can we use event-driven architecture” but “can this process 10,000 events per minute at under 200ms, without exceeding this cost per month.” If a criterion cannot be measured, it is not a criterion.
Agree the scope, the box and the stopping rule
What gets built, what is deliberately faked or omitted, how long it runs, and the point at which we stop and report — whichever way it is going.
Build the smallest thing that answers it
Real code, real data or a realistic substitute, real conditions. Everything not under test is stubbed, mocked or ignored.
Measure and report
Results against the criteria, what we learned that we did not expect, the risks that only appeared once it was running, and what it would take to make it real: effort, architecture, cost to operate.
A “no” is a successful proof of concept
This is the part most providers will not say. If the concept does not hold, the engagement has done its job — you have found out for the cost of a few weeks instead of a funded programme.
We have no incentive to deliver a positive result, because we do not need the concept to be true in order to be paid. If it fails, we tell you why, and whether a different approach would work.
What it is not
Not a prototype
A prototype tests how something looks and feels to a user. A proof of concept tests whether it can work.
Not an MVP
An MVP is a real product with a minimal feature set, released to real users. A proof of concept is not released to anyone.
Not the first version of the system
Proof-of-concept code proves a point; it is not built to be maintained. Where something is worth keeping — the architecture, the data model, the integration approach, occasionally a component — we say so. Otherwise it is thrown away, and that is the intended outcome.
Where to start
Feasibility proof of concept
One technical question answered against your data and constraints.
Option comparison
Two or three approaches built far enough to be measured against the same criteria.
Vendor or platform evaluation
A claim tested in your environment before you sign.
AI feature validation
Accuracy, latency and cost per outcome measured before anything is committed to.
Tell us what you are unsure about
If it can be settled in a few weeks, we will tell you how we would test it and what would count as proof.
- The question, the success criteria and the scope, agreed in writing before we build
- The working proof of concept, and the code
- Measured results against each criterion, and a clear verdict
- The unknowns it exposed, and the risks it did not remove
- What production would take: architecture, effort, and cost to run
- A recommendation: proceed, change approach, or stop