Decision

Build or buy: when custom software pays off

A practical way to weigh off-the-shelf tools against a custom build, including the cases where buying clearly wins.

Published 8 August 2026

Most organisations ask this question too late: only once the package has chafed for three years and a spreadsheet has grown up beside it to fill the gaps. The trade-off is simpler than it looks, as long as you make it at the right level: per process, rather than in one go for the whole company.

Buying wins more often than agencies admit

For anything that works at your company the way it works everywhere, a package is almost always the better call. Accounting, payroll, email, storage: there is no competitive advantage in those, and there are companies devoting their entire existence to them. Building custom there means paying alone for maintenance that would otherwise be shared across thousands of customers.

Custom wins where your process differs

It gets interesting with the work your company does differently from the rest, which is often exactly why customers choose you. A schedule that accounts for your machines. A pricing structure nobody else uses. An inspection process specific to your industry. Push that into a package and the familiar symptoms appear: fields that mean something other than their name, exports to Excel, and a colleague who keeps the real administration in their head.

Five signs your package has been outgrown

There is a spreadsheet beside the system holding the actual truth.
New staff need weeks, not because of the trade but because of the workarounds.
The same data is entered in two places, and the two drift apart.
You pay for modules you use for a tenth of their purpose.
The vendor says what you are asking for is not possible, and that answer has not changed in years.

The third route people overlook

It is rarely all or nothing. Often the answer is to keep the package for what it is good at and build custom around the bottleneck. Your accounting package stays; quote intake and scheduling move to a system that does follow your process and integrates cleanly. That costs less than replacing everything and delivers most of the gain.

What belongs in the comparison

Do not set licence fees against build costs. Set five years of total burden against each other: licences, the hours people lose to workarounds, the errors you repair, the migration you will eventually have to do anyway, and what leaving your vendor would cost. On the custom side: the build, the maintenance, and the fact that the code is yours.

Frequently asked

We just bought an expensive package. Wasted money?

Usually not. Replacing what works is rarely necessary. Look at where the package holds you back and whether that one piece can be built around it with an integration. That is often a fraction of a migration.

Isn't custom riskier?

Different risks. With a package the risk sits with the vendor: price rises, features withdrawn, a roadmap you do not influence. With custom the risk sits with the build and with you. Both are manageable; the difference is who holds the controls.

What if the agency stops?

Which is why code ownership is not a detail. You should have full access to the source, built on widely known technology, with documentation another team can read. Ask before you sign, not after.

How do we know whether our process really differs?

Test it: have someone who knows the package well try to lay your process into it without workarounds. If that works, you differ less than you thought. If it stalls on the same three points, you know exactly what the custom work has to solve.