Every software decision is presented as a choice between building and buying. There is almost always a third option that gets skipped in the rush to ship: not doing it at all, or not yet. The teams that age well are the ones that take that option seriously.
The third option everyone forgets
Before build-versus-buy, the honest question is whether the capability needs to exist this quarter at all. A surprising amount of proposed software is solving a problem that a process change, a configuration, or simple patience would solve more cheaply. The cheapest system to operate is the one you were disciplined enough not to build.
Build only what differentiates you
When something genuinely should be built, the test is whether it is core to what makes the business distinct. Build the thing customers would notice if it were generic; buy the thing that is the same for everyone. Nobody has ever won a market on a bespoke expense-approval workflow.
- Differentiating and core to the business — a candidate to build
- Necessary but identical to every competitor — buy it
- Neither differentiating nor urgent — defer it, on purpose
Every line of code is a liability
Software is not an asset that sits quietly on a balance sheet; it is a standing commitment to patch, secure, document, and eventually replace. The decision to build is a decision to maintain, for years, by people who may not be in the room yet. Counting that cost up front changes a lot of 'obvious' build decisions into purchases — or into nothing at all.
Good engineering is as much about restraint as output. The estate that is cheap to run and easy to secure is usually the one whose owners said 'no' more often than they said 'let's build it'.
Begin a conversation → about the systems you depend on.