Proof of Concept

Two to six weeks to answer one specific question with a working prototype.

Before a six-figure build, a focused proof of concept can settle the question that everything else hinges on. Does the model work on your data. Does the workflow survive contact with users. Is the cost defensible. A fixed-price answer, in writing.

Schedule a free first call Request a quote

Overview

The smallest possible build that produces a defensible answer.

A proof of concept is not a small version of the production system. It is a deliberately narrow build aimed at the one question that, if answered honestly, decides whether the larger investment should happen at all. We size it in weeks, not months, and we resist scope-creep on principle.

The output is a working prototype against your real data, a written readout of what the prototype proved and what it did not, and a recommendation on what to do next. That recommendation is the same whether it points at a build, an iteration, or a clean stop, we are paid the same either way.

What you get

Three deliverables, none of them slideware.

A proof of concept is judged by what it makes decidable, not by how polished the demo looks.

Working prototype on real data

A runnable prototype connected to a representative slice of your real data, including the messy parts. Source code transferred to you on delivery, regardless of which way the recommendation lands.

Written readout

A short document covering the question we set out to answer, what worked, what did not, the edge cases we hit, and what production-grade rollout would cost in engineering time, infrastructure, and ongoing operating expense.

Productionise, iterate, or stop

A single honest recommendation, not a menu of options. If the answer is to productionise we sketch what the build looks like. If it is to iterate or stop, we say that, and explain what would have to change for the answer to flip.

When this fits

Four signs a proof of concept is the right next step.

One question is blocking the decision

You can name the single unknown that, if resolved either way, would let the larger investment proceed or be killed cleanly. If there are four interlinked unknowns and you do not know which one to attack first, an Advise engagement is the better opening move, we will say so.

Your data is real, not theoretical

A representative slice of real data exists and can be made available within the first week of the engagement. Proofs of concept against synthetic or hypothetical data tell you almost nothing useful, and we will recommend pausing the engagement rather than running it on fictional inputs.

A stop is a real option

The business is genuinely willing to act on a negative result. If the build is going ahead regardless of what the prototype surfaces, the prototype is theatre, not validation, and the budget is better spent on the build itself with the unknowns accepted explicitly.

Speed matters more than polish

You would rather have a rough answer in four weeks than a polished answer in four months. A proof of concept trades production hardness for learning speed, and that trade only makes sense when the decision waiting on the other side is expensive enough to justify the haste.

Why us

Three reasons our proofs of concept produce answers you can act on.

Indifferent to the answer

We have no follow-on retainer to protect and no licensed product to sell. The recommendation that lands in the readout is the recommendation we would give if we were never to hear from you again. That is rarer in this market than it should be.

One question, defended

We push, on the first call and at every checkpoint, to keep the prototype aimed at the one question that matters. Scope creep is the failure mode that quietly turns a six-week proof of concept into a four-month half-built product, and we treat it as a risk to manage.

Honest cost estimates

The readout names what production would actually cost, engineering hours, infrastructure spend, ongoing operating expense, model spend, at a level of detail you can take to a finance review. No theoretical economics, no “at scale” hand-waving.

How it runs

Four steps from named question to written recommendation.

Compressed into two to six weeks, with the readout fixed at the end.

Define the question

Before any code is written we agree the single question the prototype is built to answer, and the criteria that decide whether the answer is yes or no. A vague question produces a vague prototype, so we push to make the success bar specific and writable on one page.

Plug into real data

We get access to a representative slice of your real data within the first few days. Synthetic data hides exactly the edge cases a proof of concept is supposed to surface, so we treat data access as a gating step rather than something to defer until the prototype is “ready”.

Build and pressure-test

Over the bulk of the window we build the prototype against your data, push it deliberately at the edge cases that worry us most, and surface what works and what does not in writing as we go. You see the in-flight notes, not a polished final reveal.

Readout and recommendation

In the final week we deliver a written readout: what the prototype proved, what it did not, what production would cost in time and money, and a single honest recommendation, productionise, iterate, or stop. The recommendation is the deliverable, not a suggestion.

Common questions

Frequently asked questions about Proof of Concept engagements.

Will the prototype be production-ready?

No, deliberately. A proof of concept that is built to ship production-ready code on day one is a proof of concept with the wrong incentives, it will avoid the edge cases that might force a rebuild. We optimise for learning, not for hardening, and we are explicit about that in the readout.

What if the answer to the question is no?

Then we say so in writing and recommend stopping. About a quarter of the proofs of concept we run end with a recommendation not to productionise, and we treat that as a successful engagement. Spending three months and a low five-figure budget to avoid a year-long six-figure mistake is the point of the offer.

Can we extend if we run out of time?

Sometimes, but rarely as a continuation of the same engagement. If the prototype surfaces a different question that also needs answering, we quote that separately as its own short engagement. Quietly extending blurs the line between proving a concept and starting to build the production thing.

Do you sign NDAs and access agreements before seeing data?

Yes, as a default. We sign mutual NDAs at the proposal stage and work to whatever data-access agreement your security team requires before any data lands in our environment. If your data cannot leave your environment at all we work inside it instead, at a slightly higher cost we will name up front.

How is this different from a free demo or a vendor pilot?

A vendor pilot exists to sell you the vendor's tool; the conclusion is decided before the pilot starts. A free demo exists to sell you a follow-on engagement. We are paid the same whether the recommendation is to productionise or to stop, which is the only way a proof of concept can produce an answer you should actually trust.

One unknown standing between you and a much larger decision?

Bring it to a free first call. If a proof of concept can settle it cleanly we will scope and quote one. If it cannot we will say so and suggest the engagement that actually can.

Schedule a free first call

…