Build vs Buy: The Decision Framework Every CTO Gets Wrong

Every CTO I know has a build-vs-buy war story. Usually it ends with “…and then we spent 18 months rewriting the thing we bought” or “…and then we realised we’d built a worse version of something that costs $50 a month.”

I’ve been on both sides. At WPP, managing a $300M cloud transformation with a $70M P&L, every build-vs-buy decision had real financial consequences. Not theoretical. Not “we might save money.” Real consequences, measured quarterly, reported to the board.

Here’s what I learned: the binary framing is the problem. It’s never build OR buy. It’s always a spectrum, and the right answer usually lives in the middle.

The real price tag: total cost of ownership

The licence fee is the estate agent’s brochure. It’s the number that gets you in the door. The real cost is everything that follows.

When I ran the numbers at WPP, a vendor’s $100K annual licence typically came with $80K of integration work in year one, $60K per year of ongoing maintenance, and an opportunity cost we could never quite quantify but knew was real. That’s a 3-year TCO of $360K for a “$100K product.”

The build side isn’t cheaper by default. A team of 3 engineers at fully loaded cost is $400-600K per year. If your build takes 6 months and then needs ongoing maintenance, you’re looking at a similar 3-year number. The difference is what you own at the end.

When you build, you own the asset. When you buy, you rent it. Neither is inherently better. The question is whether what you’re buying is something worth owning.

Core vs context: the strategic filter

Geoffrey Moore’s framework is the one I come back to most: separate core from context. Core is what makes you different. It’s what your customers pay for, what gives you competitive advantage, what you’d be crazy to outsource. Context is everything else.

A restaurant cooks its own food. That’s core. It doesn’t grow its own wheat. That’s context.

In technology, most teams over-classify things as core. I’ve seen companies build their own CI/CD pipelines, their own logging frameworks, their own auth systems. These are context. Three of your competitors use the same vendor for these things, and their customers don’t notice or care.

The test is straightforward: if you removed this capability entirely, would your customers choose a competitor? If yes, it’s core. Build it, own it, invest in it. If no, it’s context. Buy the best available option and move on.

At WPP, we built the cloud orchestration layer that let us move workloads between providers. That was core. It gave us negotiating leverage with hyperscalers and let us optimise costs in ways no vendor product could. But we bought everything underneath: the VMs, the networking, the storage, the monitoring. Context.

Vendor lock-in: the compound interest of switching costs

Lock-in isn’t a moment. It’s a gradient.

Year one, switching is inconvenient. Your team knows the vendor’s API, your workflows assume their conventions, but you could migrate if you had to. Year three, switching is painful. Your data is in their format, your monitoring depends on their metrics, your team has deep vendor-specific knowledge that doesn’t transfer. Year five, switching is a project with its own budget.

The vendor knows this. Their pricing reflects it. Year-one discounts are generous because they’re an investment in future lock-in.

The mitigation isn’t to avoid vendors. It’s to build abstraction layers. At WPP, we wrapped every major vendor integration in an internal interface. When we needed to swap providers, we changed the adapter, not the application. The abstraction layer was the strategic asset, not the underlying vendor.

Map your exit cost at 1 year, 3 years, and 5 years for every major vendor relationship. If the 5-year exit cost exceeds the cost of building, you’ve rented yourself into a more expensive mortgage.

The integration tax: the cost nobody budgets for

Every vendor has its own auth model, data format, error conventions, and upgrade cycle. Your engineers become glue-code specialists, translating between systems instead of building value.

The integration tax compounds. System A talks to B, B talks to C. Now A changes its API. The blast radius isn’t one system. It’s every downstream dependency.

By the third major vendor integration, you’re not buying productivity. You’re buying complexity. I’ve seen organisations where 30-40% of their engineering effort goes to maintaining integrations rather than building features.

Budget 30-40% of any vendor’s sticker price for integration and ongoing maintenance. If that number makes the vendor uneconomical, you’ve learned something before you signed the contract.

The hybrid path: what actually works

The real answer is almost never pure-build or pure-buy. In practice, every large-scale technology organisation I’ve worked with uses a hybrid approach:

Build the core differentiator. The thing that makes you different, the thing your customers pay for, the thing that gives you competitive distance. Own it completely.

Buy the commodity layers. Authentication, email, payments, monitoring, CI/CD. These are solved problems. Buying them lets your engineers focus on what matters.

Wrap everything in an abstraction layer. This is the part most organisations skip, and it’s the most important. An abstraction layer lets you swap vendors without rewriting your application. It’s insurance against lock-in, and it’s a strategic asset in itself.

At WPP, the cloud platform was exactly this hybrid: custom orchestration (built) on top of hyperscaler primitives (bought), wrapped in an abstraction layer that let us move workloads between AWS, Azure, and GCP. The orchestration layer was ours. The infrastructure underneath was rented. And the abstraction meant we could renegotiate with providers from a position of strength.

The decision framework

When I evaluate a build-vs-buy decision now, I ask four questions:

Is this our competitive advantage? If yes, build. If no, buy. This sounds simple but it requires honest assessment. Most things you think are core aren’t.

Can we staff and retain a team for this? Building only works if you can hire and keep the engineers to maintain it. If the talent market for this skill set is brutally competitive and you can’t compete on compensation, buying might be cheaper even when building makes strategic sense.

Will the vendor’s roadmap diverge from ours? Every vendor optimises for their median customer. If you’re an outlier, their roadmap will eventually diverge from your needs. Build an abstraction layer now, before the divergence costs you.

Is the integration cost greater than the build cost? This is the question nobody asks until it’s too late. By the third vendor, the integration overhead often exceeds what it would cost to build a simpler, purpose-built solution.

The build-vs-buy decision isn’t a one-time choice. It’s a continuous evaluation. What you buy today might need to be built tomorrow as your needs evolve. What you build today might need to be replaced by a vendor solution when the market matures.

The best CTOs I know treat it as portfolio management, not a binary decision. They build where it creates competitive distance, buy where it creates speed, and maintain the abstraction layers that make switching possible.

---

Explore the interactive Build vs Buy framework for visual diagrams, decision ladders, and the key concepts explained through business analogies.