Off-the-shelf, integrate or custom software? A decision model in four routes

Short answer. Choose in this order. If your process fits the package, adapt your process. If the package can do it with settings or an extension, do that. If two systems need to share the same data, connect them. Only when your exceptions, in-house systems or own data don't fit a package do you build custom software. It almost always ends up being a combination.

The question "off-the-shelf or custom" is usually asked too early. Then it is about taste and price, and whoever argues most convincingly wins. After mapping a process it becomes a different question. You know which steps remain, which decisions they contain and which systems are involved. The choice becomes almost technical.

This article belongs to process optimisation: map the process first, then the software that fits. Which method to use to map that process is in process optimisation models.

Route 1: adapt your process to the package

The cheapest software is software you already have. Exact Online, AFAS, Moneybird, Picqer, HubSpot and Shopify are built around the way most companies work. If your deviation from that way of working gains you nothing, adapt your process to the package.

Often such a deviation grew historically and nobody can explain anymore why it has to be that way. That happens more often than you think. It is different when the deviation is your edge. A wholesaler with its own price tiers per customer or a reseller with its own way of purchasing shouldn't polish that away to fit a package.

Route 2: extend or reconfigure the package

Many packages can do more than they are used for. Extra fields, workflows, automatic rules, or an extension from the package's app store, such as the Exact App Center or the Shopify App Store. Always ask first whether the package can already do it.

There is a limit. Making a package do something it wasn't built for with three extensions and a handful of exception rules is custom software in disguise. Only on a foundation you don't own, which can break with every update.

Route 3: connect systems

If two systems need the same data, connect them instead of re-typing. That can be a standard integration from the package, a no-code tool such as Zapier, Make or n8n, or your own integration on the API of both systems.

Connecting works well when data goes one fixed way and the rules are simple: a web shop order becomes a sales invoice in the bookkeeping. It gets hard as soon as the integration has to decide. Which VAT applies to a cross-border order? What happens with a partial delivery? Which source leads when two systems disagree? A standard integration follows the happy path and stops where your exceptions begin. Why that goes wrong so often is in re-typing between systems.

Route 4: build custom software

Custom software is built around the logic of your business. In practice it is usually a layer around the existing packages: an internal system for the exceptions, a dashboard that calculates the real margin, a portal for customers or suppliers.

Off-the-shelf software structurally falls short in three situations:

1. In-house or unusual systems. Packages expect standardised input, and orders arriving by email from ten suppliers across three mailboxes are not that.
2. Decisions that need more than if-then rules. Cost allocation, exceptions and judgement. A rules engine in a package gets stuck as soon as the logic depends on context.
3. Data that has to stay under your own control because compliance or privacy requires it.

What custom software costs and how I build it is on custom software development.

The decision model on one page

Question	Yes	No
Does your deviation from the standard way of working give you an advantage?	Go to the next question	Route 1: adapt your process
Can the package do it with settings or an extension?	Route 2: configure or extend	Go to the next question
Is it only data that needs to move from A to B, with simple rules?	Route 3: connect	Go to the next question
Does the software need to handle exceptions, use in-house systems or keep data under your control?	Route 4: custom	Back to the process: there is probably still a step to remove

Why it almost always becomes a combination

You don't choose a route for your whole company. You choose per step in the process. Bookkeeping stays in Exact Online or Moneybird, because there is nothing to gain there. The web shop gets connected. And purchasing across ten suppliers, with exceptions and cost allocation no package knows, becomes custom.

That is why I map the process first. Without that overview you pick one route for everything. Then you buy a big package that forces half your process into a straitjacket, or you build custom software for steps a package could have handled fine. Both are expensive, and I see the second more often than you would expect.