How do you make build-vs-buy decisions at organizational scale?

Question

Accepted Answer

The core principle is simple: **build what differentiates you, buy everything else.** At org scale the decision is less about a single tool and more about where you choose to spend your scarce engineering capacity.

## A decision framework

```text
BUILD when:
- It is core to your competitive advantage
- No adequate solution exists, or yours must be materially better
- The capability must evolve constantly with your product

BUY when:
- It is a commodity (auth, payments, email, observability)
- A mature vendor solution exists and fits well enough
- Time-to-market matters more than control
```

Weigh **total cost of ownership**, not just license price: integration, maintenance, hiring, and opportunity cost of the engineers not working on your product.

## Concrete example

A company builds its recommendation engine (the heart of its product) but buys its CRM, payment processing, and logging stack. Building those would burn engineers on non-differentiating work.

## Trade-offs and pitfalls

- **Pitfall:** "not invented here" syndrome, rebuilding commodities for ego or fun.
- **Pitfall:** buying for a core capability and being unable to differentiate.
- Buying creates vendor dependency; building creates maintenance debt. Choose your debt deliberately.

## Why it matters

Engineering capacity is the scarcest resource in most companies.

Spending it on commodities instead of differentiators is the most common way good teams fall behind.

Disciplined build-vs-buy is how a CTO directs that capacity toward what actually wins.