# Build vs Buy Source: John Bradshaw — https://bradshaw.cloud URL: https://bradshaw.cloud/strategy/build-vs-buy/ Type: insight Date: 2026-04-04 Updated: 2026-08-15 Tags: Strategy, Architecture > 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. ## 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. ### Total Cost of Ownership _The real price tag_ **Analogy:** 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. **Business take:** 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. ### Vendor Lock-in _Switching costs_ **Analogy:** 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. **Business take:** 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. ### Core vs Context _Strategic filter_ **Analogy:** 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?' **Business take:** 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. ### Integration Tax _Hidden cost_ **Analogy:** 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. **Business take:** 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 Hybrid Path _The CTO's real answer_ **Analogy:** 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. **Business take:** 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. ## Decision framework ### Is this capability your competitive advantage? **Yes → build (or acquire). No → buy.** Your moat lives in what you build, not what you buy. If a competitor can buy the same thing off the shelf, it's not a differentiator. ### Can you staff and retain a team for this? **No → buy, even if building looks cheaper on paper.** Building requires sustained investment in people. If the labour market for that skill is tight, the hidden cost of attrition can dwarf the licensing fee. ### Will the vendor's roadmap diverge from yours? **Yes → build an abstraction layer now. Review annually.** Vendor roadmaps serve their median customer, not you. An abstraction layer (ports-and-adapters) lets you swap providers without rewriting business logic. ### Is the integration cost greater than the build cost? **Often yes for the 3rd+ vendor. Factor integration into every buy decision.** Each vendor adds auth flows, data mapping, error handling, and monitoring. By vendor three, integration effort often exceeds the cost of building in-house. ## Frequently asked questions ### How do I decide whether to build or buy? 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. ## Diagrams Standalone SVG diagrams, licensed CC BY 4.0 with attribution to John Bradshaw — link back to https://bradshaw.cloud/strategy/build-vs-buy/ when embedding. - [Total Cost of Ownership (SVG)](https://bradshaw.cloud/strategy/build-vs-buy/diagrams/tco.svg) - [Vendor Lock-in (SVG)](https://bradshaw.cloud/strategy/build-vs-buy/diagrams/lockin.svg) - [Core vs Context (SVG)](https://bradshaw.cloud/strategy/build-vs-buy/diagrams/core.svg) - [Integration Tax (SVG)](https://bradshaw.cloud/strategy/build-vs-buy/diagrams/integration.svg) - [The Hybrid Path (SVG)](https://bradshaw.cloud/strategy/build-vs-buy/diagrams/hybrid.svg) ## Interactive companion **Build vs Buy: TCO Calculator** — Compare cumulative cost across build, buy, and hybrid paths over your chosen horizon — an interactive calculator for the build-vs-buy decision. Live calculator: https://bradshaw.cloud/strategy/build-vs-buy/calculator/ ## Related - [Read the full article](https://bradshaw.cloud/writing/build-vs-buy-framework/) — the decision framework in full, and where CTOs get it wrong. - [AI cost curves](https://bradshaw.cloud/strategy/ai-cost-curves/) — the build-vs-buy decision applied to AI infrastructure. - [Technical Debt Prioritisation](https://bradshaw.cloud/strategy/technical-debt/) — the carrying cost of everything you decided to build. - [All strategy insights](https://bradshaw.cloud/strategy/)