All field notes
Working Theory 2026.04.28

What "build vs buy" actually asks

The question on the surface is about cost. Underneath, it's about how much operating complexity your team wants to own.

What "build vs buy" actually asks

“Should we build this internally or buy it?”

The question sounds like it’s about money. It almost never is.

What the question is actually asking: how much of your team’s attention do you want to permanently allocate to maintaining this thing, versus running the business it’s supposed to support?

Building looks cheaper on a spreadsheet. The first version usually is. What the spreadsheet doesn’t model is the next two years — the on-call rotation when something breaks at 3am, the engineer who needs to learn an unfamiliar tracker API, the migration when the third-party service changes their pricing model. None of those costs show up in week one.

Buying looks more expensive on a spreadsheet. The first invoice usually is. What it doesn’t price in: the engineering attention you don’t have to spend on the maintenance treadmill. Whatever else that attention could have built.

If we’re talking to a team about a system we’d sell them, and they’re genuinely going to be better off building it themselves, we say so. That’s not generosity. It’s that the worst outcome for everyone is a team that buys infrastructure they should have built, or builds infrastructure they should have bought. Both endings are bad. The question is honestly worth thinking through, not closing.