The most expensive decision in enterprise technology is rarely the one that gets debated in the steering committee.

The debated decision is usually "which platform?" — which cloud, which vendor, which stack. The far more consequential decision is the one made silently a few weeks earlier: whether to rebuild the system, replace it, reengineer it, or accept its limitations. That decision determines the ceiling of what any subsequent platform choice can achieve. Choose wrong and vendor selection alone rarely rescues the outcome.

This playbook provides a structured way to evaluate those choices before budgets are committed, platforms are shortlisted, or engineering teams begin building.

The decision is not build-vs-buy — it is four options

The traditional framing is a binary: build our own, or buy a commercial product. That framing is increasingly incomplete in practice. It ignores two options that are often the right answer.

This framework forms one part of the broader Digital Reengineering methodology described in Digital Reengineering: A Practical Guide for Enterprise Leaders.

Build from scratch

You commit engineering capacity to constructing a system from first principles, owning the codebase, the operating model, the roadmap, and the long-term maintenance. Sensible when the system encodes proprietary business logic that constitutes competitive differentiation — logic that, if it lived in a vendor product, would be available to your competitors on the same terms.

Also sensible when the market for viable vendors is genuinely absent, which is a narrower condition than build decisions typically assume.

Bolt on a vendor solution

You license a commercial product, configure it to your context, integrate it with your existing environment, and accept the vendor's roadmap. Sensible when the capability is undifferentiated — payroll, expense management, video conferencing, standard CRM — and when the total cost of ownership over five years, including integration and change-management effort, is provably lower than building.

The bolt-on option is where many enterprises reflexively land, because vendor demos are polished and internal engineering headcount is expensive. Both of those observations are true. Neither is a decision framework.

Reengineer what already exists

You take the current system — usually a mix of custom code, vendor products, legacy databases, and manual processes — and redesign the operating model it serves, then refactor the technology to serve the redesigned model. You keep what still works. You rewrite the parts whose original assumptions have gone stale. You retire the parts that duplicate capability the reengineered model no longer needs.

Reengineering tends to be the right answer when the current system contains real business logic that you don't want to lose, when the operational context has drifted significantly from the assumptions the system was built on, and when the cost of ripping everything out is measurably higher than the cost of surgery.

Many enterprises undervalue this option because it doesn't come with a vendor demo or a rebuild "clean sheet" narrative. It requires knowing the current system honestly, which is a discipline that has to be built.

Walk away

You retire the system, absorb the loss, and change the business's expectation of what the system was meant to do. Sensible when the system was solving a problem the business no longer has, or when the cost of any of the first three options is provably higher than the value the system continues to provide.

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 five signals that tell you which option fits

Real projects rarely have a single dominant signal. The framework works by reading five signals and looking at their configuration.

Signal 1 — Where the business logic lives

Identify the logic in the system that, if lost, would materially change how the enterprise operates. Not the "features" — the actual business rules, workflows, and decisions the system encodes.

  • Logic is deep and central to differentiation → Build or Reengineer (never let it move into a vendor's IP).
  • Logic is deep but not differentiating → Reengineer (preserve it in your own operating model but use commodity technology to serve it).
  • Logic is shallow / mostly configuration of vendor defaults → Bolt on (a modern vendor will match or exceed).
  • Logic has been overtaken by market changes → Walk away (the logic is a liability, not an asset).

Signal 2 — The system's relationship to differentiation

Ask specifically: does this system, done well, help our customers choose us over an alternative? Not "help our operations run" — that describes every operational system. Does it show up in the customer's experience of the enterprise?

  • Directly differentiating → Build or Reengineer. Never outsource this to a vendor.
  • Enables differentiation but is not itself differentiating → Reengineer or Bolt on, depending on Signal 1.
  • Not differentiating → Bolt on or Walk away. Every hour spent maintaining this is an hour not spent on something that is.

Signal 3 — Organisational memory sunk into current workflows

Long-lived systems tend to accumulate a shadow curriculum: workarounds, tacit knowledge, informal review steps, and unwritten decisions that operators have built up over time. This is not always visible from the code or the documentation. It is often the difference between a system that works and a rebuild that doesn't.

  • Deep, distributed, load-bearing shadow curriculum → Reengineer (a rebuild tends to lose it; a bolt-on tends to fight it). Sensible reengineering surfaces the shadow curriculum, converts what still matters into explicit process, and lets the rest go.
  • Shallow / mostly obsolete shadow curriculum → Build or Bolt on is safer.
  • No load-bearing shadow curriculum → Bolt on or Walk away.

Signal 4 — Realistic cost of switching

The cost of switching from the current system to any of the four options. This is not the vendor's list price. It is the total, honestly estimated cost of the transition, including data migration, integration rework, retraining, temporary productivity loss, and the risk-adjusted cost of things breaking during the change window.

  • Switching cost is low → Bolt on or Walk away if the current system's continued value is also low; Build if the differentiation case is strong.
  • Switching cost is high and current-system value is decaying → Reengineer typically dominates.
  • Switching cost is high and current-system value is intact → Reengineer the parts that need it; leave the rest.

Realistic switching cost estimates are hard to produce because political pressure inside the enterprise tends to underestimate them. A useful discipline is to have the switching cost estimated by the operations leader who would run the transition — not the sponsor who champions the change.

Signal 5 — The half-life of the surrounding market

How stable is the world this system operates in? Regulatory regime, customer behaviour, competitive dynamics, technology substrate.

  • Long half-life (10+ years of stable assumptions ahead) → any of the four is potentially viable; use Signals 1–4 to decide.
  • Medium half-life (3–7 years) → Reengineer or Bolt on; a Build here needs to be architected for cheap replacement.
  • Short half-life (<3 years) → Bolt on with a clean exit contract, or Walk away and revisit. Build here rarely pays back.
  • Unpredictable half-life (AI-adjacent, regulation-in-flux) → the current era. Assume the half-life is shorter than the enterprise wants it to be. Bias to reversibility. Layering new AI capability on top of an unchanged operating model is a common failure mode in this configuration; see AI Readiness Is a Culture Problem, Not a Budget Problem for the parallel argument on the operating-model side.

Reading the signals together

The signals rarely all point the same direction. The framework's real value is in what to do when they conflict.

Three common configurations are worth calling out.

Deep-logic + high switching cost + medium half-life. This is one of the more common enterprise cases and the one where reengineering tends to be the right answer. Building risks losing the logic and often takes too long. Bolting on tends to lose the logic and force the enterprise into the vendor's model. Walking away often destroys value. Reengineering preserves what is valuable and rebuilds what is stale, on a schedule the business can absorb.

Undifferentiated logic + low switching cost + long half-life. Bolt on. The politically-charged version of this decision is "but we built this ourselves twenty years ago". That is a sunk-cost objection. The framework's answer is: acknowledge the sunk cost, and bolt on.

Deep logic + long half-life + directly differentiating. Build. This is the narrow but real case where investing in owned technology is defensible. Verify that the differentiation is real (Signal 2) before committing.

Where the playbook usually breaks down in practice

The framework is straightforward. The application isn't. Three failure modes appear consistently across programs.

Politics overrides analysis. The system's original sponsor is still senior. The vendor has an existing commercial relationship the CFO doesn't want to disturb. The IT leader has staked reputation on the previous build. All of these are real forces. The framework does not remove them; it just makes their operation visible. A leader who insists on running the framework analysis before the political conversation still has to have the political conversation, but has a coherent case to bring to it.

Sunk cost drives the wrong answer. Enterprises that have spent significant money on the current system tend to resist any option that implies the money was wasted. Reengineering is often chosen for this reason when Bolt-on or Walk-away would be correct. Or Build is chosen when Reengineer would be correct, on the argument that "if we're going to invest anyway, we might as well go all-in". Neither is a framework decision.

Vendor management inertia. Bolt-on decisions frequently outlive the conditions that made them right. The vendor's product drifts. The enterprise's needs drift. Six years later the enterprise is running a heavily-customised, half-broken deployment that was never re-evaluated. Building explicit re-evaluation windows into vendor decisions is part of the framework, not an add-on.

Where Jettifi sits in this playbook

Jettifi is a digital reengineering firm. Our position on this framework is straightforward: the reengineer column is often where enterprises have the greatest opportunity to unlock existing value, because it is frequently the option that receives the least attention. The build column gets attention because it is exciting; the bolt-on column gets attention because it is easy to procure; the walk-away column gets attention when nothing else is left. Reengineering — which requires knowing the current system honestly, preserving what still earns its keep, and rewriting the rest — is the harder discipline and, in our observation, the one that most reliably compounds.

The framework in this piece is the same one a leader can run internally. It is written to be usable without us. Where we work with a client, our role is to hold the analysis to a standard the internal team is often politically constrained from holding itself to, and to execute the reengineered operating model without discarding the shadow curriculum along the way. Those are the two places reengineering programs most often break down.

The playbook stands on its own. If it prompts a better decision in a boardroom we will never enter, it has done its job.

Closing

The playbook is not about finding the perfect answer. It is about making the decision with full awareness of what you are trading. If the reason you are debating platforms is that the underlying build-or-reengineer-or-bolt-on-or-walk-away question was never resolved, vendor selection alone rarely fixes it — and the organisational precondition for any of these options is the one covered in Why Most Digital Transformations Fail at the Org Chart, Not the Tech Stack.

Sources

  • Michael Hammer & James Champy — Reengineering the Corporation: A Manifesto for Business Revolution, HarperBusiness, 1993. Anchors the definition of the "Reengineer what already exists" option above and the underlying claim that operating-model change should precede technology substitution.
  • Michael E. Porter — "What Is Strategy?", Harvard Business Review, November–December 1996. Anchors the differentiation-vs-operational-effectiveness distinction that underlies Signal 1 ("Where the business logic lives") and Signal 2 ("The system's relationship to differentiation"). The Build and Reengineer recommendations for differentiated capability inherit from this framing.