Buy, Borrow or Build? A key question in university technology decisions

1st October 2026

When a university needs new technology capability, the options often appear straightforward.

It can Buy a specialist product.

It can Borrow capability from something already within the institutional technology estate.

Or it can Build the capability itself.

All three approaches can work.

The difficulty is that they are rarely compared on completely equal terms.

Licence costs are visible. Development budgets are visible. Implementation and integration costs can usually be estimated.

But some of the most important costs are much harder to put into the business case.

They concern domain knowledge, institutional effort, risk and time.

And those costs can ultimately matter more than the original software decision.

Buy: paying for accumulated knowledge

Buying a mature specialist product can initially appear to be the expensive option.

There is a licence. There are implementation costs. Integration is required. Procurement takes effort.

But the institution isn’t only buying software. It is also acquiring the accumulated domain knowledge embedded within that software.

A mature specialist product has already encountered many of the problems the institution is about to discover: exceptions, interactions between processes, regulatory changes, local variations and apparently sensible design decisions that behave very differently when exposed to reality.

This doesn’t eliminate implementation work or institutional choice. But it can dramatically reduce the amount of domain discovery the university has to undertake itself.

Where the product is a strong fit, this will usually provide the shortest route to operational value because the core capability already exists.

Borrow: the apparently attractive middle ground

Borrow can initially look compelling. The university already owns a capable platform. Perhaps it is the student record system, a CRIS/RIMS, an enterprise workflow product or another configurable institutional system.

Why introduce another product when something already available can be configured to do the job?

Sometimes that is exactly the right decision. But it creates a danger we explored in our previous paper, The Swiss Army Knife Problem.

A Swiss Army knife contains a screwdriver. It can tighten a screw. That doesn’t necessarily make it the tool you would choose to drive thousands of screws repeatedly.

The same distinction applies to software. A platform may contain forms, workflows, rules, notifications and reporting tools. Technically, therefore, it may be capable of reproducing many specialist processes. But capability is not the same as suitability.

If the platform doesn’t already contain the underlying domain model, somebody has to provide it. That somebody is usually the university. The institution can gradually find itself defining how processes interact, determining which exceptions matter, deciding what should be configurable, maintaining local workflows and understanding the consequences when one part of the model changes.

The apparent reuse of technology can therefore become something subtly different:

rebuilding specialist capability inside a system whose primary purpose lies elsewhere.

The more a university stretches a broad platform into a specialist domain, the more it should ask whether it is genuinely reusing capability or simply relocating the development effort.

Build: software development is only the beginning

Building internally can also be entirely rational. There may be genuinely unusual requirements. The institution may possess excellent internal development capability. Strategic control may matter. Commercial products may genuinely fail to address the requirement.

Indeed, SkillsForge itself began through university development. So we understand the attraction.

But there is something we could not have understood fully when that journey began:

The difficult part isn’t simply writing software. It’s discovering everything the software eventually needs to understand.

That distinction becomes particularly important in postgraduate research management.

A progression process can be built relatively quickly. Then reality arrives. What happens when a researcher changes study mode? What happens to future dates? What happens following an interruption or extension? Which regulations apply? How should different faculties operate legitimately different processes without fragmenting the institutional model? How do supervision, progression, candidature, examination and researcher development interact? Which exceptions deserve configurable workflows and which should simply be handled as exceptions?

Software can be built surprisingly quickly.

Domain maturity cannot.

It accumulates through years of implementations, unusual cases, policy changes, mistakes, support requests and institutions asking questions nobody anticipated when the original software was designed.

The fourth cost: waiting

There is also another cost that is easily overlooked in a conventional business case.

Time to value.

Suppose an institution decides to build. The development budget might compare favourably with the cost of buying a commercial system. But what happens while the system is being developed?

The organisation continues operating. Staff still administer the existing processes. Spreadsheets remain in use. Emails continue carrying information between people. Manual reconciliation continues. Local workarounds persist. Management may still lack the institutional oversight the new system is intended eventually to provide.

Those costs don’t necessarily appear against the software project. But they are real.

This suggests a broader way of thinking about technology investment:

Cost to acquire or build + cost to operate + cost of domain discovery + cost of waiting.

Viewed this way, time to value becomes part of the economic comparison rather than merely a project-management metric.

So which should a university choose?

There isn’t a universal answer.

Buy tends to offer the shortest route to value when a mature specialist product fits the requirement well.

Borrow can be extremely effective where requirements are relatively shallow or naturally adjacent to the purpose of an existing platform. But as specialist depth increases, the university should examine how much domain-design responsibility it is taking on.

Build offers maximum control and may be appropriate where requirements are genuinely distinctive, but it usually carries the longest and least predictable journey to mature capability because both the software and the institutional domain model have to be developed.

The important point is therefore not that one option always wins.

It is that they should be compared on the same basis.

A £1 spent on a software licence is highly visible. A £1 spent through hundreds of small amounts of staff effort, configuration, workarounds, support and continued manual administration is much harder to see. Yet economically they are still both £1. And time has a cost too.

Ask a different question

Perhaps the starting question shouldn’t therefore be:

Should we Buy, Borrow or Build?

Instead ask:

Where do we want the difficult work, risk and domain knowledge to live?

Once that question is answered, the technology decision can look rather different.

Our latest SkillsForge white paper, Buy, Borrow or Build?, explores the three strategies, their less visible costs and the questions universities can use to make a more complete comparison.

Buy, Borrow and Build are all legitimate strategies. The mistake is comparing their visible costs while ignoring where each strategy places the hidden work, risk, domain knowledge — and time.