The build-or-buy decision is usually framed as a cost comparison: the licence fee against the engineering time. Framed that way it is nearly always wrong, because it compares a price that is visible against a cost that is not, and the invisible one is larger.
What building actually costs
The estimate that gets presented is the cost of reaching a working version. That is a fraction of the commitment.
- Maintenance is permanent. Software does not stand still. Dependencies are deprecated, security patches are required, operating systems change. A system nobody is actively developing still consumes engineering time every year it exists.
- The long tail is most of the work. Reaching something that handles the common case is fast. Handling the exceptions, the error states, the concurrent edits and the malformed inputs is where the schedule goes.
- Someone must be on call. A production system needs monitoring, alerting and a person responsible when it fails at an inconvenient hour. That is an ongoing organisational commitment, not a project cost.
- Knowledge concentrates and then leaves. Internal systems are typically understood by one or two people. When they leave, the organisation owns something nobody understands and cannot safely change.
A defensible rule of thumb is that the initial build is a minority of lifetime cost. Any comparison that stops at delivery is comparing a vendor’s multi-year price against a single phase of the alternative.
What buying actually costs
The symmetric error is treating the licence fee as the cost of buying.
Implementation and integration frequently exceed the first year’s licence. Data must be migrated, staff trained, and processes adapted to how the product works. That last item is the one most often missed: buying software means adopting the vendor’s model of the process, and where that diverges from how the organisation operates, something has to give.
Then there is price escalation. Renewal terms typically include annual uplifts, and switching costs rise the longer a system is embedded — which means negotiating leverage declines exactly as the amount at stake grows.
The question that actually decides it
Cost comparison is the wrong primary frame. The better question is whether the capability is a source of competitive differentiation.
If doing something differently from competitors is why customers choose you, building it is defensible even at higher cost, because buying it means operating the same system as everyone else in your market. A vendor’s product embodies a standardised process — that is what makes it economical to produce — and standardised processes cannot differentiate.
If the capability is necessary but undifferentiated — payroll, expense management, ticketing, authentication — building it consumes engineering capacity on something that will, at best, match what is available commercially. The opportunity cost of that capacity is usually the largest number in the entire analysis and it never appears in the comparison.
Stated plainly: build what makes you different, buy what makes you the same.
Where the rule breaks
It is a good heuristic rather than a law, and three situations override it.
- No adequate product exists. Genuinely rare, and asserted far more often than it is true. The claim usually means no product matches the current process — which is an argument about whether the process is worth preserving.
- The integration cost exceeds the build. Occasionally a product’s data model is so far from the organisation’s that adapting it costs more than building something aligned.
- Regulatory or data constraints. Some jurisdictions and sectors restrict where data may be processed in ways that eliminate most vendors.
Note that “our requirements are unique” is not on this list. Most organisations that believe their requirements are unique have accumulated idiosyncratic processes rather than distinctive ones, and are proposing to spend engineering capacity preserving accidents of history.
The third option
The framing as a binary is itself part of the problem. The most common good answer is to buy the platform and build the differentiated layer on top of it — using a vendor for the commodity substrate and internal engineering for the part that is actually specific.
This requires evaluating vendors partly on the quality of their interfaces and export capabilities rather than only on features, which is a different procurement conversation. It also preserves optionality: a well-bounded internal layer over a replaceable substrate is far easier to migrate than a monolith of either kind.
Whichever way the decision goes, the discipline that makes it real is costing the alternative honestly — including the exit. An organisation that has never calculated what leaving a vendor would cost has no negotiating position, and one that has never costed maintenance is not comparing like with like. It is the same arithmetic that governs infrastructure choices generally, which we worked through in the economics of cloud repatriation.
