The Build vs. Buy Decision for Operational Platforms

At some point every operations leader who's felt the integration tax and mapped their sprawling stack arrives at the same fork: do we build the operational layer that ties everything together, or do we buy it?

The instinct is to frame this as control versus speed. Build it and you get exactly what you want; buy it and you get it fast. That framing isn't wrong, but it's incomplete — and it quietly ignores that both roads have a well-populated graveyard.

The Graveyard on the "Build" Side

Building feels safe because you stay in control. The data says otherwise.

The most rigorous study of the question — McKinsey's research with the University of Oxford across more than 5,400 large IT projects — found that large IT projects run, on average, 45% over budget and 7% over schedule, while delivering 56% less value than predicted. Worse, 17% of them go so badly wrong they threaten the existence of the company. Software projects carry the highest risk of all.

The pattern holds industry-wide. The Standish Group's CHAOS research has tracked software outcomes for three decades and still finds roughly one in five projects fails outright, and around half are "challenged" — late, over budget, or missing features. Two decades of Agile haven't moved these numbers much; there's a "complexity ceiling" that methodology alone can't break through.

None of this means "never build." It means build with clear eyes about the odds.

The Graveyard on the "Buy" Side

Buying has its own failure mode, and it's quieter — no dramatic write-off, just slow erosion.

You buy the product. It fits 70% of how you work. The remaining 30% becomes workarounds: spreadsheets alongside the tool, manual steps to bridge what it doesn't do, and processes bent to fit the software rather than the other way around. You've bought speed, but you've also bought someone else's assumptions about how your operation should run — and re-created the very fragmentation you were trying to solve.

Buying fails when you buy a product for a problem that was actually about fit and connection, not features.

Decide With Evidence, Not Instinct

Because both paths have real risk, the decision deserves more than a gut call. Five factors do most of the work: how much the capability differentiates you, whether you have the team to build and maintain it, how well off-the-shelf products fit, how urgent time-to-value is, and your appetite for owning maintenance forever.

Answer honestly and the lean usually becomes clear.

The Third Option Nobody Frames

Here's what the binary misses: build-versus-buy was never a binary. Between "buy a rigid product" and "build everything from scratch" sits the option that's right most often — compose.

Composing means building your differentiating workflows on top of a proven foundation — established integrations, a shared data layer, and platform primitives you don't have to reinvent. You get the fit and control of building where it matters, with much of the speed and lower risk of buying everywhere else.

This is why the smart move is rarely to write a ground-up platform or to accept an off-the-shelf product as-is. It's to buy or adopt the commodity foundation, and build only the thin layer that's genuinely yours on top of it. The McKinsey data backs this instinct: the projects that failed were the big, ground-up, multi-year efforts. Keeping scope tight and building on existing foundations is exactly how you stay out of the 45%-over-budget cohort.

What This Means for an Operational Platform

For the specific case of an operational layer — the thing that connects your systems, workflows, and reporting — the calculus tilts further toward compose, for one reason: the hard, risky part is the plumbing, and the plumbing isn't your differentiator.

Integrations, a reliable shared data model, workflow orchestration, access control, audit — every organisation needs these, and none of them is where you win. Building them from scratch is taking on the highest-risk part of the McKinsey dataset to produce something no customer will ever thank you for. What is worth owning is the layer that encodes how your operation actually runs — the workflows, rules, and views specific to your business.

So the pragmatic architecture is almost always the same: a proven operational foundation underneath, your differentiating operational logic on top. Buy or adopt the plumbing. Build the part that's yours.

The Path Forward

The build-versus-buy decision goes wrong when it's treated as a matter of temperament — builders want to build, buyers want to buy. Treated as a matter of evidence, it's calmer: most capabilities aren't differentiating enough to justify the risk of building, most off-the-shelf products don't fit well enough to adopt wholesale, and the honest answer for the operational layer is usually to compose.

Decide deliberately. Weigh differentiation against risk. And when you do build, build narrow, build on foundations, and ship in increments — because the graveyard is full of teams who built broad, built from scratch, and shipped in one big bang.

Weighing build against buy for your operational layer? Start the conversation — we'll help you separate the plumbing from the parts that are genuinely yours, and design the path that carries the least risk for the most fit.

---

Sources

1. McKinsey & Company, in collaboration with the University of Oxford. Delivering Large-Scale IT Projects on Time, on Budget, and on Value. 2012. mckinsey.com — across 5,400+ large IT projects, average 45% budget overrun, 7% schedule overrun, and 56% benefits shortfall; 17% qualify as "black swans" that can threaten the company; software projects carry the highest risk.

2. The Standish Group. CHAOS Report 2024, as analysed in Comparative Research on IT Project Failure Rates: A 2025 Longitudinal Update (PM World Journal, Jan 2026). pmworldjournal.com — roughly 31% of software projects succeed, ~50% are challenged (late/over budget/missing features), and ~19% fail outright; success rates have stagnated for a decade.