Build-vs-Buy Total Cost
Comparing a purchased solution against building one on the full lifetime cost, including the maintenance and opportunity costs that estimates omit.
The comparison is systematically biased towards building, because the build estimate covers construction and the buy price covers everything.
What a fair comparison includes on the build side: initial construction, which is the only part usually estimated; ongoing maintenance, conventionally a substantial fraction of build cost every year, indefinitely; the operational burden of running and supporting it; the feature gap that will be requested once it exists; key-person risk; and the opportunity cost of the engineers, who are the scarcest resource and are not working on the differentiating product.
And on the buy side, beyond the licence: integration effort, configuration and customisation, training, vendor management, the risk of price increases at renewal, and the exit cost if it fails.
The heuristic that resolves most cases: build what differentiates, buy what does not. If a capability is why customers choose you, control it. If it is undifferentiated — identity, payments, observability, email delivery, feature flags — buying it is nearly always correct, and the engineering argument that it could be built in a fortnight is usually true and beside the point, because the fortnight is not the cost.
The failure to guard against is the middle path: buying a product and then customising it so heavily that you have taken on build-level maintenance without build-level control, and lost the vendor's upgrade path in the process.