Most build-versus-buy decisions are not decisions. They are predispositions wearing the costume of analysis. The team that likes building will build a case for building. The team that fears owning software will build a case for buying. The executive in the room is handed two documents that each look rigorous and is asked to pick, when what actually happened is that the conclusion was chosen first and the analysis was assembled to support it.
This is part three of a six-part series on technology modernization for executives. Part two covered what the program really costs. This part covers the fork you reach once the budget is real, and it adds the option that almost never appears on the slide: leave it alone.
The third option, again
In part one I argued that doing nothing is a legitimate choice with a real, nameable cost. It belongs here too, because build-versus-buy is usually presented as a binary when it is a trinary. Before you choose how to replace a system, confirm that replacing it now beats leaving it for another year. If the system is not generating attributable cost, the correct answer to "build or buy" is "neither, not yet." That answer will be unpopular with whoever assembled the two documents, which is a reason to take it more seriously, not less.
When buying is the trap
Buying feels safe because someone else owns the software. The trap is what you give up. An off-the-shelf platform encodes someone else's assumptions about how the work is done. If your business does that work the way everyone else does, the assumptions fit and buying is right. If the way you do that work is part of how you compete, the platform will quietly force you back toward average, and you will spend years and significant money configuring it to resist its own defaults. That configuration is debt. It breaks on every upgrade, and you are now captive to the vendor's roadmap, paying to maintain the gap between what they built and what you needed.
When building is the trap
Building feels like control. The trap is that you become a software company by accident, and you are not staffed, structured, or funded to be one. The cost of custom software is not the build. It is the decade after the build: the maintenance, the security patching, the person who understands it leaving, the rewrite when the framework it was built on ages out. Companies routinely underwrite the construction and silently assume the ownership is free. It is not. It is the larger number, and it is the one nobody puts on the slide because it lands after the people who approved the build have moved on.
The three questions
You do not need to be technical to make this call. You need to answer three questions honestly, in order. If the order is followed, the answer usually reveals itself.
1. Is this how you compete, or is this plumbing? If the capability is part of why customers choose you, building or heavily tailoring may be justified, because handing it to an off-the-shelf platform hands it to your competitors too. If it is plumbing, payroll, accounting, the standard back office, buy it. Building plumbing is a way to spend scarce engineering capacity on something a vendor already solved better.
2. Will the requirement be stable for a decade? Custom software is a ten-year commitment whether or not you planned it that way. If the requirement is stable, that commitment is sound. If the requirement changes every two years, you are signing up to rebuild repeatedly, and a configurable bought platform absorbs that change far more cheaply than your own codebase will.
3. Can you sustain it for a decade? Be honest about whether you will fund maintenance, retain the people, and own the security and upgrade burden every year, not just in the budget cycle where it is approved. If the honest answer is no, build is off the table regardless of how well it scores on the first two questions, because an unmaintained custom system is a liability that compounds.
If a capability is how you compete, the requirement is stable, and you can genuinely sustain it, building is defensible. If any one of those is false, buying is usually the lower-risk path. If the system is not actually costing you anything yet, the framework does not apply, because you have not earned the decision.
Why the framework beats the two documents
The two rigorous-looking documents fail because they argue conclusions. The three questions work because they are answerable by the people who run the business, not only the people who would build or operate the software, and because they force the honest constraint, can you sustain this, into the open before the decision rather than after it. The most expensive build-versus-buy mistakes I have seen were not wrong analyses. They were correct analyses of the wrong question, decided by whoever wanted the outcome most.
If you are holding two persuasive documents and an uneasy feeling that the decision was made before you got it, that is a conversation worth having before you commit.
This is part three of a six-part series. Part four covers the decision you reach if you choose to buy: how to evaluate a vendor when you are not technical.
Frequently asked questions
Should we build or buy enterprise software?
Buy it unless the capability is genuinely how you compete, the requirement is stable for a decade, and you can sustain ownership for that long. If all three are true, building is defensible. If any one is false, buying is usually lower risk.
What is the real cost of building custom software?
The decade of ownership after the build, not the build itself. Maintenance, security, key-person risk, and the eventual rewrite typically exceed the construction cost and are routinely left out of the business case.
When is buying off-the-shelf software a mistake?
When the work it governs is part of how you compete. Off-the-shelf platforms encode average practice, and configuring one to resist its own defaults creates upgrade-fragile debt and captivity to the vendor's roadmap.
Is "do nothing" a valid answer to build versus buy?
Yes. If the current system is not generating attributable cost, neither building nor buying is justified yet. Build-versus-buy is a trinary, not a binary, and the third option is frequently the correct one.