delidecTry the demo →

delidec / Research / CTO

CTO · The Systems ArchitectTechnology Lens24 May 2026

Build, Buy, or Borrow: The Architecture Decision That Compounds

Few decisions compound like architecture. The choice to build, buy, or borrow a capability sets the cost structure and option space for years. This paper offers a decision framework that weighs reversibility, strategic distinctiveness, and total cost over time.

Why architecture compounds

Most decisions are paid for once. Architecture is paid for continuously. The choice of how a core capability is built — in-house, purchased, or assembled from someone else’s components — sets the cost of every feature that follows, the speed at which the team can move, and the range of futures that remain reachable. Small early advantages compound into large structural ones; small early mistakes compound into debt that constrains the company for years.

The three options and their hidden costs

Building maximizes control and distinctiveness at the cost of time and ongoing maintenance. Buying maximizes speed at the cost of dependence on a vendor’s roadmap and pricing. Borrowing — open source or a platform API — splits the difference but inherits the provider’s constraints and risks. Each option carries a cost that does not appear on the initial invoice: maintenance for build, lock-in for buy, fragility for borrow. The decision fails most often because these hidden costs are discovered late.

Reversibility and the strategic core

Two questions discipline the choice. First, is this capability part of the strategic core — the thing the company must be distinctively excellent at — or is it undifferentiated plumbing? Build the core; buy or borrow the rest. Second, how reversible is the decision? A capability that is cheap to swap out later can be acquired quickly and revisited; one that will be load-bearing and expensive to replace deserves deliberation up front.

A decision rule

The synthesis is a simple rule with hard judgment inside it: build what is both core and durable, buy what is neither, and borrow what is non-core but fast-moving — while keeping the interface clean enough that any borrowed or bought component can later be replaced. The goal is not to make the perfect choice today but to avoid foreclosing the choices the company will need tomorrow.

← All researchPut a question to the board →