Build vs. Buy

Build vs. buy is the recurring decision about whether to develop a capability in-house or license it from a vendor. The comparison is almost always framed wrongly, as the cost of building against the cost of a subscription, when the honest comparison is the total cost of owning the thing for as long as you will need it against the total cost of renting it — including the exit. Building looks cheap because the first version is the cheapest part. What follows is the real bill: maintenance, security patching, dependency upgrades, edge cases discovered in production, on-call coverage, documentation, the compliance work required if it touches personal data, and the opportunity cost of the engineers doing all of that instead of working on whatever actually differentiates your business. Buying looks expensive because the price is visible and recurring, but the vendor amortises that same maintenance across every customer, and their price is the sum divided many ways. The useful heuristic is differentiation. Build what your customers pay you for and what would be worse if it were the same as everybody else's; buy what is table stakes, undifferentiated, and well served by a competitive market — authentication, billing, email delivery, analytics, transcription, observability. A second test is rate of change: capabilities that are moving quickly are expensive to keep up with and cheap to rent, which is why most teams buy rather than build in fast-moving areas like AI infrastructure. Whichever way you go, price the reverse: a build should be costed with five years of maintenance and a bus factor, and a buy should be costed with switching cost and the renewal uplift included, so the two numbers are actually comparable.