Build-versus-buy goes wrong in both directions, and the two failures look nothing alike.
One organization builds a bespoke expense management system because its process is unique, and spends the next decade maintaining software that does slightly worse what forty vendors sell. Another buys a package for the operational core it actually competes on, then spends five years and a great deal of money fighting the vendor's data model to make it behave like the thing it should have built.
Both decisions came from the same mistake: answering "is this differentiated?" by intuition, in a room where everyone already had a view.
Differentiation is narrower than it feels
A useful test: if a competitor did this exact thing in exactly the way you do it, would you lose anything? Not "would changing it be disruptive" — would you lose an advantage that a customer would actually notice?
Most internal processes fail that test comfortably. They feel distinctive because of accumulated local convention: the approval chain that exists because of an incident in 2014, the three extra fields a departed VP wanted, the exception handling built for a client relationship that ended years ago. That is path dependence. It is not differentiation, and it is not worth building software to preserve.
For most enterprises the genuinely differentiated surface is small and identifiable. It tends to be the pricing or risk model, the customer-facing experience, and the operational core the business actually competes on — the thing that, done better than the competition, wins work. Everything else is table stakes executed at varying quality, and table stakes are what the software industry is extremely good at selling you.
The discipline is in being honest about how small that list is. Organizations that build only what is on it end up with far less software and far more capacity to make it excellent.
The cost you forget to model
Build cost gets modeled as a project. It is not a project. It is an annuity.
What follows the build: maintenance and dependency upgrades, forever. On-call coverage for a system that now has to be available. Security patching and vulnerability response on a clock you do not control. The knowledge risk when the three people who understood it move on, which they will. Documentation that has to be maintained or the previous item gets worse. And a compliance workstream every time a regulation changes, because now that is your problem rather than a vendor's.
A reasonable rule of thumb from what we see in practice: the ongoing annual cost of owning a bespoke system is a meaningful fraction of what it cost to build, every year, for as long as it runs. A business case comparing a one-time build cost against several years of license fees, while omitting that entire side of the ledger, is not a comparison. It is an argument with numbers attached.
Buy has its own recurring costs and they should be modeled with equal honesty: integration work, upgrade cycles, configuration drift, and the permanent risk that the vendor's roadmap diverges from your requirements. But those costs are usually smaller, and the system is somebody's actual product rather than your side project.
Heavy configuration is building
The most expensive outcome is neither build nor buy. It is a package customized so far beyond its intended use that it carries build-level maintenance cost with buy-level architectural constraints.
It is visible well before it becomes terminal. Custom code in the vendor's extension framework grows faster than configuration does. Upgrades stop being routine and become projects with their own budgets. The support answer to your questions becomes "that is not a supported configuration." Integration work routes around the product's own interfaces because they do not do what you need.
Once you are there, you own a bespoke system that you cannot fully control, cannot easily upgrade, and cannot cheaply leave. It is the worst position available, and organizations arrive at it incrementally, one reasonable-sounding customization at a time.
If requirements genuinely demand that much divergence, treat it as evidence. Either the capability is differentiated and should have been built deliberately, or the requirements themselves deserve a serious challenge — and it is usually the second.
A framework worth using
Four questions, applied per capability rather than per system.
How differentiated is it — would a competitor copying it cost you something a customer would notice? How fast do the rules change, and who controls them: you, a regulator, or a market? How deep is the integration — how much of the estate touches this capability? And what is the exit cost if this decision turns out to be wrong in five years?
High differentiation with a high rate of change points to build; you need control of both the logic and the release cycle. Low differentiation and stable rules points to buy, and to resisting customization with real discipline. High integration depth and high exit cost means that whichever you choose, the investment belongs in the boundary — a clean interface that lets you replace what sits behind it without touching everything else.
The per-capability framing matters more than the questions. Most systems bundle several capabilities with genuinely different answers, which is why serious analysis so rarely produces a clean win for one side. It usually produces something like: buy the platform, build the two capabilities that actually differentiate us, and invest properly in the seam between them.
That answer is less satisfying than picking a side. It is also the one that tends to still look correct in five years.