Build vs Buy

The build-versus-buy decision is the fork in the road for every software capability: commission your own, or license someone else's. Neither path is safer by default — one rents you flexibility at the price of ownership, the other delivers speed at the price of dependence. Most expensive technology mistakes are not execution failures but forks taken on the wrong criteria.

What It Is

Build vs buy is the evaluation of whether to develop a capability in-house (or via commissioned development) or license it from a vendor. A disciplined comparison looks beyond licence versus development cost: total cost of ownership on both sides over a realistic horizon, time-to-capability, strategic differentiation (build what differentiates you; buy what doesn't — the classic heuristic), integration burden, exit costs in each direction, and the organisation's genuine ability to run what it builds (development is a career, not a project). The modern addendum is a third path: configure — buy a platform and build only the differentiating layer on top of it.

Why It Matters to You

The decision rule executives most often get wrong is treating commodity capabilities as differentiators. Payroll, authentication, document storage — building these burns scarce engineering capacity on things no customer will ever pay for; the defensible exception is when the 'commodity' carries your core IP or regulatory obligation. The second error is underestimating the buy side's tail: data export friction, per-seat cost curves, roadmap dependence. A sound decision papers the reasoning — because in three years, the organisation will need to know whether the choice failed or the world changed.

When You'll Meet It

At the start of any significant capability investment, and at renewal points when accumulated dependence can be reassessed. Insist the comparison includes exit costs on both branches — that single discipline corrects most biases.