Why Build versus Buy Is Really an Investment Decision

We’ve all been there.  Aging systems no longer fit for purpose. Time to consider a new engine. Unfortunately, not as simple as trading in the old Model T for a new Audi. The business truism aptly defines the complication – trying to swap out the engine while keeping the plane flying.

Too often, organizations believe the most important technology decision is whether to Build or Buy.

I don’t think it is.

The real decision is whether the assumptions behind that choice have been documented, validated, and revisited over time.

Technology projects, like heart transplants, require rigorous planning before the first incision.

The Problem

We start by debating opinions.

• “We can build it.”
• “It’ll only take twelve months.”
• “We only need three more developers.”

None of those are business cases. They’re beliefs.

What about logical incrementalism? Start moving. The answers will evolve. Isn’t that what Agile gives us?

But Agile is a development methodology. It is not a substitute for enterprise planning.

Agile answers the question:

• “What should we build next?”

It does not answer:

• “What must exist before this business can operate?”

We still need a destination, an enterprise roadmap, dependencies, a capability model, and an investment model.

Don’t confuse those with Waterfall as opposed to Agile.

The Missing Document

Before a single line of code is written, the hardest work is often building the decision framework itself.

The framework mandates consideration of three core prerequisites:

• Business objectives
• Current state
• Required capabilities

Even with a framework, organizations often reduce the decision to a false choice: Build versus Buy. The better question is which combination creates the greatest business value:

• Build.
• Buy.
• Hybrid.

Each alternative deserves documented facts—not opinions.

• The cost model.
• The resource model.
• The timeline.
• The risks.
• The expected benefits.
• The implementation dependencies.
• The decision dashboard.

But wait… Even organizations that faithfully produce these documents often miss one critical column.

• Evidence.

Every estimate should answer one simple question.

• What evidence supports this assumption?

Suppose we say a task should take two developers three weeks. The estimate sounds objective because it is precise.  But to estimate developer productivity, can we tie it to completed work? Comparable implementations? Vendor experience? Historical velocity?

Or is it simply optimism?

One of Agile’s greatest strengths is that every completed workstream becomes evidence for the next estimate.

• How many developers?
• How many months?
• How many defects?
• How much testing?
• How much rework?

Actual performance becomes the calibration point for future estimates.

Not because every project is identical.

Because reality is more valuable than hope.

So we’ve nailed the plan. Real hours, real costs, real evidence.  Sorry.  One more important element. One of the most important assumptions is also one of the least documented.

• Opportunity cost.

Every engineering month spent rebuilding commodity functionality is capital that cannot be invested elsewhere creating competitive differentiation.

So we are still at the starting line with our framework.  We have to continually ask:

• What must we uniquely own?
• What should we leverage?
• Where does AI actually create competitive advantage?

Those questions are every bit as important as asking whether something can be built.

The Executive Questions

We don’t ask, “Can we build it?”

We ask, “Should we?”

Then we keep asking, with all of the attendant framework questions.

• At what cost?
• Compared with what alternative?
• With what probability of success?
• Within what business window?

The bottom line: Technology decisions are investment decisions.

Investment decisions deserve documented assumptions.

CFOs do not approve major capital investments because someone is confident. They approve them because assumptions, alternatives, expected returns, risks, and opportunity costs have been documented.

Technology deserves exactly the same discipline.

The investment decision is not made just once. As evidence replaces assumptions, the investment case should be revisited. Priorities change. Costs change. Markets change. AI changes what is practical to build and what is better to buy.

Because Build, Buy, or Hybrid is not fundamentally a technology decision.

It is a capital allocation decision.