Build, buy or modernise?

Almost every technology leader eventually faces the same question.

Do we build it?

Do we buy it?

Or do we modernise what we already have?

There is no universally correct answer.

The mistake is treating the decision as primarily technical.

It is a business decision expressed through technology.

When should you buy?

Buying generally makes sense when the capability is important but not differentiating.

Payroll is the obvious example.

Most organisations do not gain competitive advantage from creating their own payroll engine.

The same may apply to accounting, collaboration, CRM, HR systems and many standard enterprise capabilities.

Mature products can provide proven functionality faster and with less implementation risk.

Buying can offer:

Faster time to value.

Predictable functionality.

Vendor support.

Established security practices.

Continuous product development.

But buying creates dependencies too.

Licensing.

Vendor roadmaps.

Integration constraints.

Customisation limitations.

Data portability.

Potential lock-in.

The cheapest initial implementation isn't necessarily the lowest long-term cost.

When should you build?

Custom software makes most sense when technology contributes directly to differentiation.

Perhaps the organisation operates in a way standard platforms cannot accommodate.

Perhaps the customer experience itself is strategic.

Perhaps unique data, workflows or intellectual property create competitive advantage.

Perhaps available products require so much customisation that the organisation effectively ends up building around them anyway.

Building creates control.

But control has a price.

The organisation becomes responsible for maintaining, securing, operating and evolving the platform.

Custom software is not a project.

It is an asset with a lifecycle.

When should you modernise?

This option is often overlooked.

An existing platform may look old while still containing enormous business value.

Years of proven logic.

Integrations.

Operational knowledge.

Customer history.

Reliable processes.

Replacing everything may destroy value unnecessarily.

Modernisation can preserve the parts that work while changing the architecture around them.

A monolith can be decomposed progressively.

Interfaces can be rebuilt.

APIs can expose existing capabilities.

Infrastructure can be modernised.

Manual processes can be automated.

Data can be restructured.

Specific components can be replaced.

The right answer is sometimes neither "keep it" nor "replace it."

It is evolve it.

Understand before deciding

This is why discovery matters.

Before deciding to replace a legacy platform, understand what it actually does.

Map dependencies.

Analyse integrations.

Understand data.

Document business rules.

Identify pain points.

Determine operating costs.

Understand security exposure.

Identify what genuinely constrains the business.

AI-enabled code analysis can increasingly accelerate this discovery process, particularly in large undocumented systems.

Better understanding produces better decisions.

Calculate total cost, not purchase price

Build-versus-buy discussions often compare implementation budgets.

That is too narrow.

Consider:

Licensing.

Development.

Integration.

Infrastructure.

Support.

Upgrades.

Security.

Specialist skills.

Vendor management.

Migration.

Change management.

Future customisation.

Exit costs.

A solution that appears expensive today may be cheaper over ten years.

A solution that appears inexpensive may become extremely costly once the organisation is deeply dependent on it.

Consider strategic control

Ask a simple question:

If this capability becomes dramatically more important to our business over the next five years, how much control will we wish we had?

That changes the conversation.

A commodity capability may belong with a vendor.

A strategic capability may deserve ownership.

And sometimes the best architecture combines both.

Hybrid is often the answer

Modern enterprises rarely need an ideological position on build versus buy.

They need an architecture that allows both.

Buy commodity capabilities.

Build where differentiation matters.

Modernise valuable existing assets.

Connect them through well-designed integration.

Maintain control of critical data.

Avoid unnecessary dependencies.

This is less elegant than a simple rule.

It is also closer to reality.

The decision can change

What you buy today may become strategic tomorrow.

What you build today may become commoditised.

What you modernise today may eventually deserve replacement.

Technology strategy therefore needs optionality.

Architectures should allow organisations to change direction without rebuilding everything around them.

Start with the business

Before asking build, buy or modernise, ask:

What problem are we solving?

How strategic is this capability?

How quickly do we need it?

What already exists?

What would replacement disrupt?

What control do we require?

What skills do we possess?

What will this decision cost over its lifetime?

What happens if our assumptions change?

Then choose the technology.

Build where it differentiates.

Buy where the market has already solved the problem well.

Modernise where existing technology still contains value.

The objective isn't to own the most technology.

It's to own the right technology — and retain enough flexibility to evolve when the answer changes.