Abstract

"Buy vs build" is one of the most consequential decisions in any software portfolio. This paper provides a framework that goes beyond cost comparison, examining strategic differentiation, vendor risk, total cost of ownership, and the hybrid patterns that often outperform pure-buy or pure-build choices.

The standard framing is incomplete

Most buy-vs-build analysis stops at: "Buy is faster and cheaper now, build gives you control later." That framing is technically true and operationally useless. It ignores the dimension that matters most: does this capability differentiate you in your market?

The differentiation axis

Capabilities fall into four categories:

  • Differentiating and core. The thing you sell. Build.
  • Differentiating but supporting. Something you do better than competitors. Mostly build, sometimes augment with a vendor.
  • Commodity and core. Required, but commoditised. Buy.
  • Commodity and supporting. Required but nobody cares how. Buy the cheapest decent option.

If a capability is commodity, building it is almost always wrong. If it's differentiating, buying it is almost always wrong. The interesting cases are the ones that look commodity but aren't quite.

Total cost of ownership

SaaS costs accrue continuously. Custom builds have a high upfront cost and lower ongoing costs. The crossover is usually 3-5 years for moderate-complexity capabilities.

The TCO calculation that's frequently missed: the cost of not having the capability at all during the build period. If buy-now-build-later is the option, you usually buy first.

Vendor risk

SaaS vendors get acquired, raise prices, pivot, and shut down. The probability of each is non-zero on a 5-year horizon. Risk mitigations:

  • Use open standards where possible. Auth via OIDC, data via standard schemas.
  • Maintain export capabilities. Know how to leave.
  • Avoid deep customisation of vendor products. Configuration over modification.
  • For mission-critical vendor relationships, have escrow or alternate options identified.

The hybrid model

Often the right answer is neither pure buy nor pure build:

  • Buy the platform, build the differentiation. Use a SaaS as a foundation, build custom on top.
  • Build the contract, buy the implementation. Define your interface, swap implementations as needs evolve.
  • Build the orchestration, buy the components. The integration is yours; the parts come from vendors.

This model lets you capture differentiation while leveraging commodity infrastructure.

Decision framework

For each capability under consideration, score these dimensions:

  1. Strategic differentiation (1-5)
  2. Operational criticality (1-5)
  3. Available vendor maturity (1-5)
  4. Internal team capability (1-5)
  5. Estimated 5-year TCO ratio (buy/build)

Aggregate scores guide the decision. High differentiation + high team capability → build. Low differentiation + good vendor options → buy. Mixed signals → consider hybrid.

Common mistakes

  • Building commodity infrastructure because "we want control" — the maintenance cost outweighs the control benefit.
  • Buying differentiation because "it's faster" — you've outsourced your competitive advantage.
  • Building because "vendors don't fit our exact needs" — most "exact needs" are imagined.
  • Buying then customising heavily — you've taken the worst of both worlds.

Recommendations

  • Be ruthless about what's differentiating. Most things aren't.
  • Default to buy for commodity capabilities. Free up engineering capacity for what differentiates you.
  • Build the seam, not the system. Design for replaceable vendors.
  • Re-evaluate periodically. What was right two years ago may not be right now.

Conclusion

The buy-vs-build decision is fundamentally about strategy, not engineering. Approach it as a strategic question — what differentiates us? — and the engineering answer usually follows. Approach it as an engineering question, and you'll over-build and under-deliver on strategy.