What a standard package does well
A good standard ERP, TMS or WMS comes with years of continued development, a large user base, and proven integrations. Implementation timelines are predictable, costs are transparent, and the vendor handles updates and compliance changes. For companies with a relatively generic operation where processes largely fit the package, this is the rational choice. In that case, the total cost of ownership is lower than custom development, and the risks are smaller.
When does a standard package break down?
The problem starts when the operation works slightly differently than the package expects. At first it is small workarounds: an extra spreadsheet here, a manual step there. After a few years, the system is surrounded by glue: integrations nobody understands anymore, daily Excel exports that require manual effort, and processes that staff run outside the system because doing it inside the package is too cumbersome. At that point you are paying the licence costs of a standard package while effectively running a hybrid of the package plus custom layers around it. The worst of both worlds.
What is the concrete difference with a custom core system?
A custom core system is built around your operation, not the other way around. That means the data structure, workflows, and automation logic align precisely with how you work. No adapting your process to fit the package. It sounds more expensive, and the initial investment is. But the comparison has to be fair: set against the custom investment the true costs of the standard package, including licences, implementation partners, customisation modules, integration work, and the maintenance of all workarounds. That total tends to look less favourable for the package than the first quote suggests.
Is there a middle ground?
Yes. If the core system works well enough but the operation stalls on specific tasks, such as processing documents, sending out quotes, or handling incoming orders, replacing the core system is not necessarily the answer. In that case you can build an AI layer that handles those specific tasks and connects to the existing system. That is a different investment with a different risk profile. The choice comes down to one question: is the pain in the core system itself, or in a handful of processes around it?
How do you make the choice in practice?
Start with an honest inventory of where the operation is currently getting stuck. Not what the system officially supports, but what staff do outside the system every day. If that amounts to one or two isolated processes, an AI worker or targeted automation is likely the faster route. If the pain is structural and spread across the entire system, a new core system is the better long-term choice. A rule of thumb: if you manage more than a quarter of your operational processes outside the package, the package is no longer your core system. It has become an expensive archive.