The decision framework every CTO faces — when to build, when to buy, and when to compose. A structured way through the trade-offs that define your stack.
5 concepts 4 decision paths Calculator
Share
The build-buy spectrum
Two different lenses depending on what kind of capability you're evaluating.
When building wins
Capabilities that justify the investment in custom engineering
Core differentiator
What makes you different
Justified
Unique data model
No vendor fits your shape
High
Regulatory requirement
Compliance demands control
Necessary
No viable vendor
The market gap
Last resort
Building is expensive — but for your core differentiator, it's the only option that compounds.
When buying wins
Capabilities where speed and maturity outweigh control
Commodity function
Email, auth, payments
Low
Time-to-market critical
Speed beats perfection
Medium
Mature vendor ecosystem
Battle-tested at scale
Medium
Team capacity constrained
Can't hire fast enough
Trade-off
Buying is fast — and for commodity functions, your engineers have better things to build.
The key concepts
Click each concept to see the business analogy and visual explanation.
The real price tag
Total Cost of Ownership
"Buying a house vs renting — the mortgage is just the start"
The licence fee is the estate agent's brochure. The real cost is the mortgage, insurance, maintenance, renovations, and the time you spend fixing the boiler on a Sunday. Build projects have the same hidden layers: hiring, onboarding, infrastructure, on-call rotas, and the opportunity cost of everything else your team isn't building.
At WPP, every build-vs-buy decision went through a 3-year TCO model. The surprise was never the headline cost — it was the integration, training, and ongoing maintenance that doubled or tripled the sticker price.
The real price tag
Total Cost of Ownership
"Buying a house vs renting — the mortgage is just the start"
The licence fee is the estate agent's brochure. The real cost is the mortgage, insurance, maintenance, renovations, and the time you spend fixing the boiler on a Sunday. Build projects have the same hidden layers: hiring, onboarding, infrastructure, on-call rotas, and the opportunity cost of everything else your team isn't building.
At WPP, every build-vs-buy decision went through a 3-year TCO model. The surprise was never the headline cost — it was the integration, training, and ongoing maintenance that doubled or tripled the sticker price.
Switching costs
Vendor Lock-in
"Changing banks — possible but painful enough that you never do"
Every year you stay, the switching cost climbs. Your data is in their format, your team knows their API, your workflows assume their quirks. It's not that you can't leave — it's that leaving gets more expensive every quarter. The vendor knows this, and prices accordingly.
Lock-in isn't binary. Map your exit cost at 1 year, 3 years, and 5 years. If the 5-year exit cost exceeds the cost of building, you've just rented yourself into a more expensive mortgage.
Strategic filter
Core vs Context
"A restaurant cooks its own food but doesn't grow its own wheat"
Core is what makes you different — the thing customers pay for. Context is everything else: payroll, email, logging, CI/CD. The strategic question isn't 'can we build this?' — it's 'should we spend our best engineers on this, or on the thing that actually differentiates us?'
Most teams over-classify things as 'core'. If three competitors use the same vendor for it and customers don't notice, it's context. Build only what creates competitive distance.
Hidden cost
Integration Tax
"Every new appliance needs a different adapter"
Each vendor has its own auth model, data format, error convention, and upgrade cycle. Your engineers become glue-code specialists — translating between systems instead of building value. By the third integration, you're not buying productivity; you're buying complexity.
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. Budget 30-40% of vendor cost for integration and maintenance.
The CTO's real answer
The Hybrid Path
"You don't build or buy — you compose"
The real answer is almost never pure-build or pure-buy. You build the core differentiator, buy the commodity layers, and wrap everything in an abstraction that lets you swap vendors without rewriting your product. The architecture is the strategy.
At WPP, the cloud platform was a hybrid: custom orchestration layer (built) on top of hyperscaler primitives (bought). The abstraction layer was the strategic asset — it let us move workloads between providers without rewriting applications.
Start with one question: is this capability your competitive advantage? If a competitor can buy the same thing off the shelf, it is not a differentiator, and you should buy it too. Then sanity-check the answer against three constraints — whether you can staff and retain a team for it, whether the vendor's roadmap will diverge from yours, and whether integration will cost more than the build. The answer is rarely pure build or pure buy.
What is the difference between core and context?
Core is what makes you different — the thing customers actually pay for. Context is everything else: payroll, email, logging, CI/CD. A restaurant cooks its own food but does not grow its own wheat. The strategic question is never "can we build this?" but "should our best engineers spend their time on this, or on the thing that creates competitive distance?" Most teams over-classify work as core.
What is the integration tax?
Every vendor arrives with its own auth model, data format, error conventions, and upgrade cycle, and your engineers become glue-code specialists translating between them. The cost compounds: when one system changes its API, the blast radius is every downstream dependency. Budget 30–40% of vendor cost for integration and maintenance, and expect that by the third vendor the integration effort often exceeds the cost of building in-house.
Why does total cost of ownership matter more than the licence fee?
Because the licence fee is the estate agent's brochure. The real cost is the mortgage, the insurance, the maintenance, and the Sunday spent fixing the boiler. Build projects have exactly the same hidden layers — hiring, onboarding, infrastructure, on-call rotas, and the opportunity cost of what your team is not building. Run every decision through a three-year model; the surprise is never the headline number, it is the integration and maintenance that double or triple it.
What is the hybrid path?
Build the core differentiator, buy the commodity layers, and wrap the lot in an abstraction that lets you swap vendors without rewriting your product. The architecture is the strategy. A ports-and-adapters layer over bought primitives is more work up front, but it is the asset that lets you move a workload when the commercial terms change — which is precisely when you have no time to re-architect.
How do I protect against lock-in without building everything myself?
Map your exit cost at one, three, and five years, and treat the trend as the signal. Lock-in is not binary; the switching cost climbs every quarter you stay, because your data sits in their format and your workflows assume their quirks. If the five-year exit cost exceeds the cost of building, you have rented yourself into a more expensive mortgage. An abstraction layer is the cheapest insurance against that.
