Stackbook Logo
decision-makingestablished · low operational burden

Build vs Buy Decision

Also known as: make-or-buy, build-buy-borrow

Intent

Decide systematically whether to build a capability in-house, buy a product, or adopt open source.

Problem

Teams default to building because it is interesting or to buying because it looks fast. Both ignore total cost of ownership, differentiation, and exit cost. The result is either reinvented commodities or critical paths owned by vendors.

Forces

  • •Engineering capacity is finite and has opportunity cost
  • •Differentiating capabilities need control and speed of change
  • •Commodity capabilities have mature, cheaper vendor options
  • •Integration, migration, and exit costs are easy to underestimate

Solution

Overview

Build vs buy is a structured way to decide where engineering effort should go. The question is not whether you can build something, but whether building it creates advantage that justifies owning it forever. Every built component brings on-call, security patching, upgrades, and hiring needs.

A third option, borrow, covers open source and managed open-source offerings. It often sits between the extremes: low license cost, but you accept upgrade, patching, and community-risk responsibilities. Reassess when scale, regulation, or vendor pricing shifts the balance.

How it works

Score each option against weighted criteria, then compute total cost over a fixed horizon.

capability: audit-log-search
class: generic            # core | supporting | generic
options:
  build:  { year1: 400k, run: 120k/yr, exit: low }
  buy:    { year1: 150k, run: 180k/yr (growth 15%), exit: medium }
  oss:    { year1: 220k, run: 90k/yr, exit: low }
revisit_when: "volume > 5TB/day or vendor price +25%"

In practice, run a short time-boxed spike against a real workload, score reliability, security posture, API fit, and data portability, and have finance validate the cost curve at two and ten times current volume. Include the people cost of operating whichever option wins.

Pitfalls

  • Counting only license cost and ignoring integration, security review, and training
  • Underestimating run cost of self-built systems, which usually exceeds build cost within three years
  • Treating the decision as permanent instead of setting revisit triggers
  • Skipping a proof of concept against real data before committing

Key takeaways

  • Build what differentiates, buy what is generic
  • Compare total cost over several years, including exit
  • Write the decision and its revisit triggers in an ADR
  • Prototype with production-like data before signing

✓ When to Use

  • •Starting a new capability with credible vendor options
  • •Renewing a large contract or reviewing homegrown tooling
  • •Choosing between managed service and self-hosting

✗ When Not to Use

  • •The capability is clearly the product itself
  • •Regulation mandates a specific approach
  • •The decision is cheap and reversible within a sprint

Pros

  • +Focuses engineers on differentiating work
  • +Makes cost and risk assumptions explicit
  • +Produces an auditable decision record

Cons

  • −Scoring models can be gamed to justify a prior preference
  • −TCO estimates are uncertain beyond a year
  • −Adds process overhead for small choices

Cost Profile

Infrastructure

Varies by outcome

Operational

Low - a review per decision

Cognitive

Medium - requires TCO modeling

Failure Modes

  • Building a commodity because of not-invented-here bias

  • Buying a product that cannot be exited when pricing changes

  • Ignoring integration and customization cost in the TCO

Real-World Examples

Alternatives

    Related Patterns

    • architecture-decision-records
    • technical-debt

    Competency Domains

    economics evolutionrequirements constraints