Build Versus Buy Is a Risk Decision. Most Companies Only Price One Side of It.

Every build-versus-buy debate I have sat in eventually turns into a spreadsheet. Engineering months on one side, licence fees and integration cost on the other. Whichever number is smaller wins.

That framing quietly assumes the two options carry the same risk. They do not. Building and routing are both risk decisions, and they hand you completely different risks. The cost model prices one and ignores the other, which is how companies end up surprised by an outcome they technically chose.

What we decided to own

I run a three-person company. That constraint removed any illusion that we could build everything, so we had to be explicit about the rule.

We build the interface, the wallet, the cross-chain plumbing and the AI layer. Perpetuals route to Hyperliquid via builder codes. Prediction markets route to Polymarket. On paper that reads like a cost decision, because building a matching engine or an oracle stack would have taken quarters we did not have. That is not why we did it.

We routed because those systems already work at production scale, and the risk of shipping a worse version of a solved problem is higher than the risk of depending on someone who solved it. We kept the wallet and the custody model in-house for the opposite reason. Those are the parts where a failure is not recoverable and where a vendor decision would be effectively permanent.

That is the actual rule we use. Own what you cannot reverse. Route what you can.

The risk you keep when you build

Building does not remove risk. It converts vendor risk into execution risk, and execution risk is the one finance teams are worst at pricing because it does not arrive as an invoice.

When you build, you carry the possibility that the thing ships late, ships worse, or ships into a market that has already moved. You carry the maintenance obligation for as long as the product lives, which almost never appears in the original business case. You also carry the opportunity cost of the work your team did not do instead, and that number is usually larger than the licence fee that triggered the debate.

None of that shows up in the build column. It shows up two years later as a system nobody wants to own and a roadmap that did not happen.

The risk you take when you route, and why it is usually mispriced

Routing has a real and specific cost. You inherit someone else's uptime, someone else's roadmap, and someone else's commercial decisions. If they change terms, deprecate an interface, or fail, that becomes your problem on their timetable rather than yours.

The mistake is not taking that risk. The mistake is not pricing it.

On 19 July 2024, a faulty update from a single security vendor took down around 8.5 million Windows machines. Delta Air Lines later put its own cost at roughly 550 million dollars, split between a 380 million revenue hit and 170 million in recovery expense, and insurers estimated the total hit to US Fortune 500 companies at about 5.4 billion. Almost none of those companies had made a reckless procurement decision. They had made an ordinary one, and never asked what happens to us on the day this fails.

That is a concentration risk question, and it belongs in the finance function rather than in procurement.

Three questions that price it properly

We ask three things before routing anything, and all three are answerable in an afternoon.

What is the blast radius on the worst day? Not whether the vendor is reliable, but what specifically stops working, for how many users, and whether we can degrade gracefully instead of going dark. If the honest answer is that the whole product stops, that dependency needs a different structure.

How long is the exit? We measure switching cost in weeks of engineering time, not in dollars, and we make sure someone has actually traced the path rather than assuming one exists. Our rule is that a routed dependency should be replaceable in about two weeks. If it cannot be, we are not routing, we are marrying.

Is the failure reversible? A pricing dispute is reversible. A partner outage is survivable. Losing custody of user assets is neither, which is why that part was never a candidate for routing regardless of what it would have saved.

Where this lands for a finance leader

The useful reframe is that you are never choosing between risk and no risk. You are choosing which risk to hold, and the two options fail in different directions.

Build when the failure is irreversible, when the capability is genuinely yours, or when no credible provider exists. Route when the problem is solved, when the exit is short, and when the worst day is survivable. Then write down the risk you accepted, with the blast radius and the exit path, so the decision can be reviewed by whoever inherits it.

Most organisations document the cost case and lose the risk case entirely. Two years on, nobody remembers what was considered, only that the choice now looks obvious or negligent depending on how it turned out.

The spreadsheet was never wrong. It was just answering a smaller question than the one being asked.