Custom Software or Off-the-Shelf ERP: How to Decide

The honest answer is usually "buy" — and here is how to tell when it is not.

Every few months a manufacturer or clinic asks us to build something a product already does. We usually talk them out of it. Custom software is expensive to build, and far more expensive to own — someone has to keep it patched, hosted and understood for as long as the business runs on it. A product spreads that cost across thousands of customers. You cannot beat that on price.

So the question is never "which is better". It is: where is your process genuinely different, and is that difference worth paying for?

Start by separating the process from the preference

Most of what feels unique about how a company works is habit rather than advantage. The order of fields on a form, the colour of a status, the fact that approvals go to Priya before they go to accounts — none of that is a reason to build software. A configurable product will absorb it, and if it will not, the process can usually change without harm.

What does not bend is the part your customers pay you for. A contract manufacturer whose scheduling logic is the reason it hits delivery dates competitors miss has something worth encoding. A clinic that books appointments like every other clinic does not.

Write down your process end to end, then mark each step: is this how we compete, or just how we happen to do it? If almost nothing is marked, buy the product.

Compliance changes the arithmetic

The strongest case for building is a regulatory obligation no product covers. GMP manufacturing needs batch genealogy, deviation handling and QC release gates that survive an audit. Schedule H2 needs serialisation tied to a verification path. If the products in your category treat those as add-ons, or handle them for a different jurisdiction, you will spend the licence fee and still be non-compliant.

This is why our production planning platform exists. The scheduling itself is not exotic — it is the audit trail wrapped around it, and the fact that a regulator can follow a batch from raw material to release, that made an off-the-shelf tool untenable for the manufacturers we built it with.

Count the integration cost, not the licence

Comparisons usually stop at the subscription price. That is the smallest number in the decision. The real cost is what it takes to make the product talk to everything else you run — accounting, payments, the machines on the floor, the lab system, the messaging your staff already use.

A product with a documented API and a few hundred pounds of connector work is cheap. A product that requires a data-entry job to keep two systems agreeing is not, and that cost recurs every month forever. Ask for the integration list before you ask for the price list.

The year-three question

Both options look fine in year one. The difference shows up later.

With a product, you inherit someone else's roadmap. When they deprecate the module you depend on, or move upmarket, or get acquired, you absorb it. With custom software, you inherit the maintenance. If nobody budgets for it, the system quietly rots until it is the thing everyone is afraid to touch.

Neither is a reason to avoid the choice. It is a reason to be honest about it up front: with a product, ask what happens if they change direction; with a build, put maintenance in the budget from the first release rather than discovering it in year three.

A short test

If a product covers around eighty per cent of your process, buy it and adapt the remaining twenty. If it covers half, look harder — you are probably comparing against the wrong category. If the gap is a compliance obligation or the specific thing you win business on, build, and build only that part.

The best outcome is often both: a product for the general work, and something custom for the narrow slice that actually differentiates you, connected properly.

Auto Production Planning is one example of that narrow slice — batch scheduling, QC release and a regulator-ready audit trail for pharmaceutical plants, sitting alongside whatever handles the general work. Where the honest answer is build, that is what Software Development covers.