The standard comparison is dishonest
Most build-versus-buy analyses start from the wrong place. The typical exercise compares a known purchase price — the vendor's quote, easy to obtain — against an imagined build cost produced by someone with incentives to make it look favourable. The purchase price is real. The build estimate is speculative. Treating them as the same kind of number is the first error.
The second error is what gets included. Build estimates routinely cover initial development and omit everything else: ongoing maintenance, infrastructure, tooling, updates to keep pace with platform changes, incident response, and the time of whoever owns the thing afterwards. Vendor pricing, meanwhile, often omits integration work, the licensing terms that change when you scale, and the migration cost you will pay when you eventually leave.
A comparison built this way is not an analysis. It is a permission slip for a decision already taken. The honest first move is to acknowledge that, and to run the analysis in a way that could actually produce a different answer than the one you started with.
The real question is not cost but which capability you are willing to make permanent
The more useful question is not which option is cheaper today, but which of two futures you are choosing. Buying commits you to a vendor's roadmap, pricing model, and continued existence. Building commits you to a maintenance burden, the knowledge required to run the system, and the decision about whether it deserves continued investment when other priorities emerge.
Neither commitment is inherently wrong. What is wrong is choosing between them based on a first-year cost comparison when the actual stakes are about the following decade.
A capability that is peripheral to what your customers pay you for — billing, scheduling, communication, document management — is almost always better bought. The reason is not that vendors are more competent, but that you are not going to invest seriously in improving it, and a vendor who sells only that thing will. The calculus changes when the capability is what your customers are directly paying you for. At that point, ceding it to a third party means ceding the ability to differentiate.
Three costs that are consistently omitted
The purchase price and the build estimate are the visible figures. Three other costs appear consistently in these analyses and are consistently underweighted.
Integration cost. Every piece of software has to connect to everything else. The integration work — authentication, data mapping, error handling, the edge cases that only appear in production — is routinely estimated at a small fraction of what it actually takes. This is true of both options: buying something does not eliminate integration work, it changes where it lives. The cost does not disappear; it becomes ongoing maintenance of glue code rather than one-time build work.
Maintenance cost. Built software requires maintenance: bug fixes, dependency updates, security patches, adjustments when adjacent systems change. Bought software outsources most of this but retains some: API changes, deprecated features, vendor-initiated migrations. The maintenance burden for bought software is lower, but it is not zero, and projecting it as zero is a common error.
Option value. The most consistently underpriced cost in a buy decision is the option value you forfeit. Buying a system means accepting its model of the world — its data structures, its workflows, its integration points. Changing that later requires either working around the vendor's model or migrating away from it. Both are expensive. Building preserves the option to change the system's behaviour precisely as needed. That option has real value, and it is forfeited at the moment of purchase.
Why 'we can always replace it later' is usually wrong
Once data and process have accreted around a tool, replacing it costs far more than anyone estimated at the time of the original decision. The standard rejoinder to concerns about vendor lock-in is that the software can be swapped out if it becomes a problem. This is technically true and practically false in most cases.
What makes replacement expensive is not the software itself but what grows around it. Once a system is in production, processes form around it. Data accumulates in its proprietary format. Adjacent systems develop integrations against its specific API. People build institutional knowledge of how it behaves. Workarounds for its limitations become load-bearing infrastructure.
By the time replacement is seriously considered, you are not replacing a piece of software. You are dismantling an ecosystem and building a new one while running the existing one in parallel through the transition. The cost is not the cost of building the replacement. It is the cost of migration — and migration is typically two to three times what a greenfield build would have been.
This is not an argument against buying. It is an argument for making the decision knowing that the implicit assumption of easy replaceability is usually wrong.
The narrow conditions under which building genuinely wins
Building is the right answer in a specific and limited set of circumstances. The clearest signal is when the capability is directly on the critical path of the value your customers pay you for, and when you intend to invest seriously in improving it over time.
Consider a hypothetical company whose product is a data analysis tool. The analysis engine is the product. Buying an analysis platform and reselling access to it may be viable as an early-stage move, but it immediately creates a ceiling: the vendor's roadmap limits what can be offered, the vendor's pricing limits margins, and the vendor's data model constrains the questions customers can ask. In this case, the build cost is the cost of having a product at all.
A second condition: when you have genuinely tested the buy option and found that no available product adequately fits the requirement. This sounds obvious, but it matters. The build decision should always be tested against the actual market. If available vendors require significant customisation to handle your workflow — meaning you are effectively building on top of them regardless — you may be paying twice.
Outside these conditions, the default should be to buy. Not because buying is always better, but because the discipline of assuming you will buy forces you to be specific about why you would deviate from it.
Making the decision falsifiable
The most useful thing you can do before making this decision is write down, in advance, what evidence would change your mind.
If you are leaning towards buying: what build cost would cause you to reconsider? What capability limitations in the available vendors would change your answer? If the vendor raised prices significantly in three years, would that move the decision — and if so, at what threshold?
If you are leaning towards building: what ongoing maintenance cost would make you reconsider? What would you stop doing in order to sustain this? Who owns it when the person who built it leaves?
Writing the answers down serves two purposes. First, it reveals whether the decision is based on evidence or preference. If you find that no evidence would change your mind, that is useful information about the quality of your analysis. Second, it gives you a basis for revisiting the decision later — when the vendor raises prices, when your team's capacity changes, when the competitive landscape shifts.
The goal is not certainty. Build-versus-buy decisions are made under uncertainty, and the uncertainty does not resolve itself by working harder on the spreadsheet. The goal is a decision you can defend on its merits and revisit on the evidence.