The build-versus-buy debate is a false binary. Enterprises facing a system decision actually have four choices, and the third and fourth are usually the ones that determine outcome.
The four options are build, bolt on, reengineer, and walk away. Framing the decision as a two-way choice systematically undervalues the third and fourth, which are often the highest-value options.
The four options in one paragraph each
Build. Construct the system from first principles, own the codebase, the operating model, the roadmap, and the long-term maintenance. Sensible when the system encodes competitive differentiation and the vendor market for it does not exist on defensible terms.
Bolt on. License a commercial product, configure it to context, integrate it. Sensible when the capability is undifferentiated — payroll, expense management, video conferencing, standard CRM — and the five-year total cost of ownership is provably lower than building.
Reengineer. Take the current system and redesign the operating model it serves, then refactor the technology to serve the redesigned model. Preserve what still works. Rewrite what has gone stale. Retire what duplicates. Sensible when the system contains real business logic worth preserving and the operational context has drifted from the assumptions the system was built on.
Walk away. Retire the system, absorb the loss, change the business's expectation. Sensible when the system was solving a problem the business no longer has, or when the cost of any of the first three options exceeds the continuing value.
Why the binary framing fails
The build-versus-buy conversation happens because it is the easiest conversation to structure in a steering committee. Build has an obvious cost profile. Buy has an obvious vendor conversation. Both fit into a spreadsheet.
Reengineer does not fit into a spreadsheet neatly. It requires knowing the current system honestly, which is a discipline that has to be built, and it requires acknowledging that some parts of the current system should survive while others should not. Walk away does not fit into a spreadsheet at all — the cost of continuing is invisible and the political cost of admitting expired value is high.
So the third and fourth options systematically get less airtime than they deserve, and the enterprise defaults to build or bolt on because those are the options with visible sponsors.
When reengineering dominates
Reengineering tends to be the right answer in three common configurations.
- Deep logic + high switching cost + medium half-life. Building loses the logic. Bolting on loses the logic. Walking away destroys value. Reengineering preserves what is valuable and rebuilds what is stale.
- Previous transformation programmes have technically succeeded but stalled at the outcome layer. Another platform will reproduce the pattern. The failure is at the operating-model layer, which is where reengineering starts.
- Heavily-customised existing deployment that outlived the conditions that made the original decision correct. The vendor product has drifted. The enterprise's needs have drifted. Ripping out the deployment loses accumulated operational memory; adopting a new vendor commits to fresh drift.
When walking away is the right answer
Walking away is politically the hardest option because someone sponsored the system originally and someone is currently accountable for its uptime. Organisations tend to resist admitting a system's value has expired. This resistance is why walking away tends to be the most underused option in the framework.
The signals that walking away is correct: the system was solving a problem the business no longer has, the market has moved past the problem the system addresses, or the cost of any other option exceeds the value the system continues to provide.
The full decision framework
The choice among the four options depends on five signals — where the business logic lives, the system's relationship to differentiation, the organisational memory sunk into current workflows, the realistic cost of switching, and the half-life of the surrounding market. The full framework is developed in The Reengineering Playbook.
Further reading
- The Reengineering Playbook — the full five-signal decision framework for choosing among the four options.
- Digital Reengineering: A Practical Guide for Enterprise Leaders — the discipline that makes the four-option decision meaningful.
- Why Most Digital Transformations Fail at the Org Chart, Not the Tech Stack — the failure pattern that makes the third option (reengineer) the highest-value one enterprises most often undervalue.
Sources
- Michael Hammer & James Champy — Reengineering the Corporation: A Manifesto for Business Revolution, HarperBusiness, 1993. Foundational text on the reengineering option and the sequencing claim behind it.