Skip to main content

Engineering

Package or custom: a decision to make process by process

The buy-versus-build question produces bad answers when it is asked about an entire organisation at once. Asked one process at a time, it usually answers itself.

6 min read B-Softsys

Most organisations frame this as a single decision. Do we buy a platform, or do we build one? Framed that way, it has no good answer, because the honest response for almost every business is "some of each" — and which parts fall on which side is exactly the information the question throws away.

A more useful version asks the question once per process.

Where packages win comfortably

Payroll. General ledger. Expense claims. Email. Standard HR records.

These processes are similar across organisations because they are shaped by external forces — tax law, accounting standards, banking rules — rather than by anything a business chose. When your process is the same as everyone else's, a vendor amortising development across thousands of customers will always beat your internal team on cost, and usually on compliance too.

Building here is almost always a mistake, and it is a mistake that keeps costing. Every regulatory change becomes your problem.

Where packages get expensive

The signal to watch for is not that a package "cannot do it". Modern platforms are configurable enough that most things are technically possible. The signal is what the configuration costs — in licence tier, in consulting days, in the number of steps a user now takes, and in what breaks at the next vendor upgrade.

When a process has been refined over years and is part of why the business wins, forcing it through a generic model usually means one of two things. Either you keep the process and pay heavily to bend the system around it, or you quietly adopt the vendor's process and give up the advantage. The second is more common, because it is invisible in the project plan.

A practical test

Three questions tend to settle it:

  1. Would a competitor doing this exactly our way be at an advantage? If yes, that process is probably worth owning. If the honest answer is that any reasonable approach works, buy.
  2. How much configuration does the package need to fit? A little is fine. When you are into custom fields, custom workflow and custom reporting on the same process, you are building software with worse tools and a licence fee attached.
  3. What is the five-year cost of each path? Include licence escalation, upgrade projects, integration work and the internal time spent on workarounds. Custom software is usually cheaper to buy and more expensive to keep; packages are the reverse. The crossover point matters more than the first invoice.

The integration bill

Whichever way each individual decision goes, the result is a mixed estate — and the cost of a mixed estate is integration.

This gets underestimated consistently, because integration work has no natural champion. Nobody presents a reconciliation job to the board. But the manual bridging between two systems that do not talk is a recurring tax, paid in staff time and in errors that surface weeks later, and it compounds silently as the estate grows.

If you take one thing into the decision, make it this: when you choose a package, budget for connecting it, not just for licensing it.

  • AI 7 min read

    Why AI pilots stall, and what closes the gap

    The distance between a convincing demo and a system people rely on is an engineering problem, and it is mostly about what happens when the model is wrong.

    Read article
  • Cloud 5 min read

    Cloud migration that earns its cost

    Moving a server unchanged usually buys a larger bill and the same operational problems. The return comes from what you change along the way.

    Read article