Prove the one assumption that could sink your build, before you spend the budget

What a Proof of Concept Is Really There to Prove

The natural instinct, when you commission one, is to ask it to test whether the idea works. That instinct quietly overloads the exercise. A proof of concept cannot sensibly test a whole idea, and it should not try. It exists to attack a single point: the riskiest technical assumption, the one unknown the entire project depends on and the thing most likely to fail.

The discipline that makes this work is subtraction. Everything you are already confident can be built (the screens, the reports, the login, the workflow) is deliberately set aside. None of it is proven here, because none of it is in doubt. The small budget goes entirely on the part that could sink the build, and nothing else earns a line of code.

A common shape makes this concrete. Picture a system whose whole value depends on pulling clean, reliable data out of a twenty-year-old ERP or line-of-business database. If that integration cannot be made to work, no amount of polished dashboard sitting on top of it matters. So you prove the integration first, against real records, and ignore the parts you already know how to build.

That riskiest assumption tends to take one of four shapes: a hard third-party or legacy integration, an unproven algorithm, an approach that only counts if it holds up on your actual messy data (calling the OpenAI or Anthropic Claude API to check whether the clever bit genuinely works on your records, for instance), or behaviour under real volume rather than a tidy demo dataset. Name which one you are facing, and the proof of concept writes its own brief.

Proof of Concept vs Prototype vs Minimum Viable Product

These three terms get used interchangeably, sometimes by the same vendor in the same meeting, and the mix-up costs real money in misdirected budget. The proof of concept vs prototype confusion is the one that trips owners up most, because both arrive early and both look like a rough first version of the thing. The cleaner way to separate all three is not by where they sit in a build schedule but by the question each one answers for you as the buyer. A prior question usually sits above them all, which is whether to build at all or buy something off the shelf. Once you have decided to build, the three diverge sharply.

Where the doubt is genuinely technical, whether the hard part can be made to work at all, a proof of concept is the right first spend. Knowing when to insist on one, and when to skip it entirely, is the next thing to settle.

When to Insist on a Proof of Concept, and When to Skip It

The bias in this trade runs one way. An agency profits from selling a validation phase, so the reflex is to recommend one whatever you are building. Paying for a proof of concept on well-trodden, solved software is waste, and an agency worth hiring will say so rather than bill you for reassurance the work does not need. The test is where the risk actually sits: the more the whole build's success hangs on one thing nobody has proven yet, the more a proof of concept is worth insisting on before you commit budget. Occasionally the question points further back, to whether the right call is not to build the thing at all.

The dividing line is feasibility. Once the parts are known to work, the only real questions are time and money, and a different set of signals applies.

What a Proof of Concept Should Cost, and the Quote That Has Drifted

A proof of concept is small by design, and its price should reflect that. Expressed as a proportion of the full build, it usually sits in the single digits to low double digits: often under 10 per cent, rarely more than around 15. In effort, that is days to weeks, never an open-ended stretch of billing. It should reach you as a capped fixed fee, an agreed price for an agreed question, settled up front. Time-and-materials defeats the purpose here, because the whole point of the exercise is to cap your exposure before the large commitment, not to start a meter running.

When the quote has drifted, the number gives it away. If a proof of concept is priced at a third, a half, or more of the whole project, its scope has slid from attacking one risk to quietly building the product. That is an unbudgeted first phase of the build wearing a de-risking label, and it strips out the cheap-failure protection you were paying for.

One question keeps a vendor honest: what single question does this prove, and why does answering it take this much. A crisp answer is a good sign. A vague or sprawling one means the scope has wandered. For where the full costing conversation lives, see the full picture of what a bespoke build costs.

What You Receive: Working Code and a Written Go or No-Go

A proof of concept leaves you holding two things, and only two. The first is working code that answers a single question: it runs the risky part and shows whether it holds, or it shows the wall you would have hit at full budget. This is not a polished app and it is not something to ship. The second is a short written recommendation, a plain go or no-go, that reads the code back to you in language you can act on.

• ✓
  The recommendation A clear go or no-go, stated in one line before any of the reasoning.
• ✓
  The evidence What the code actually did, where it strained, and the numbers or behaviour that back the call.
• ✓
  The pre-agreed success and kill criteria The line drawn before the work began, so the verdict is measured against it rather than against hindsight.
• ✓
  A rough full-build steer On a go, a first sketch of what the complete application would then involve.

The criteria are what settle the argument, and you sign them off before a line of code is written, so the vendor is measuring its work against a line you drew, not marking its own homework after the fact. On a go, that steer feeds straight into how the full application gets scoped and built. On a no-go, the harder discipline applies. Having already paid, the sunk cost fallacy pulls you towards pressing on regardless, and the point of the exercise is to let a genuine no-go stop the project there.

Time-Boxed, Happy-Path Only, and Built to Be Thrown Away

A proof of concept stays cheap because it runs on a fixed clock. The work is scoped as a technical spike, a term borrowed from the Spike Solution in Kent Beck's Extreme Programming: a short, deliberately rough experiment that answers a technical question and nothing else. When the clock runs out, the spike ends in whatever state it has reached.

It touches only the happy path, the single straight-line case where everything goes right. Security, error handling, edge cases, and polish all wait, because none of them bear on the one question. Discarding the code afterwards feels wasteful, but you were never buying code to keep. You were buying an answer, and stripping out everything that does not produce it is what keeps the spike fast and cheap. When the question suits them, rapid-build tools like Bubble or Retool reach that answer sooner still.

Four Kinds of Technical Risk Worth Proving First

The riskiest assumption you identified earlier rarely stays abstract. In software it tends to take one of four recognisable shapes, and putting a name to yours is what turns a vague worry into a test you can actually run. Each shape answers a different question, so read them and see which one fits the build in front of you.

Where a Proof of Concept Sits, and How It Quietly Goes Wrong

A proof of concept is an optional gate, not a mandatory stage every build passes through. Before it comes discovery, which scopes the real problem and tells you whether a technical risk worth retiring even exists. After it comes a minimum viable product or the full build, once the unknown is settled. You reach for a proof of concept only when there is genuine doubt the thing can be built at all.

The trap: the most expensive proof of concept is the one that quietly becomes your live system because it "already works". The throwaway code was written happy-path only, with no security and no error handling, and every corner it deliberately cut is now a fault in software you depend on. Two smaller failures sit alongside it: gold-plating the proof past its one question, and proving the part you were never worried about while the real risk goes untested.

A Cheap Way to Protect an Expensive Decision

A proof of concept is a cheap way to protect an expensive decision. It spends a little to interrogate the one assumption that could sink the build, before the full budget is committed and hard to claw back. Plenty of projects skip it and are right to: well-trodden software, built many times over, carries little worth testing.