The trade-off between standard and custom is one of the most structuring decisions in an ERP project. Projects that fail, or that cost far more than planned, almost always have one of two problems: too much custom development, which builds technical debt, or a standard imposed without adapting enough to the real processes. The real subject behind this trade-off is not technical — it is the maturity of the organisation's processes.
The real cause of custom code is not functional — it is resistance to change
ERP vendors have enriched their standard functionality considerably. A modern ERP covers the great majority of an organisation's processes, provided those processes are allowed to evolve alongside the system. That is where the real difficulty sits: resistance to change turns, without fail, into requests for custom development.
A process that is well defined, stable and documented can generally be covered by the standard with suitable configuration. A poorly defined process, with frequent exceptions and rules that vary case by case, generates custom code — because it was not rationalised enough before the project. That is why we treat functional scoping as a prerequisite, not a formality.
Three categories of development, three levels of risk
- Workarounds: developments that compensate for a refusal to change existing processes. These are the riskiest — they build technical debt and block version upgrades.
- Functional additions: functionality genuinely absent from the standard, for business needs of real value. Sometimes justified, but rare in practice once the need is analysed in depth.
- Integrations: connections with other systems. Often unavoidable, they have to be architected cleanly so they survive change — which is the purpose of system integration.
The riskiest moment is the requirements-gathering phase. That is when users express their working habits as non-negotiable requirements, and when project teams — under schedule pressure — sign off on developments that deserved a discussion.
A custom development costs three times over its life cycle
When it is built, at every update, and at every major version upgrade. Over five years, the total cost can come to two or three times the initial one. The cumulative effect is consistently underestimated: each development looks reasonable taken on its own. It is the accumulation over three to five years of operation that turns an ERP that was "standard with a few specifics" into a system that is hard to maintain.
The rule we apply on the projects we support: 80% standard, 20% strategic custom, reserved for the processes that constitute a genuine competitive advantage — not for reproducing existing working habits.
Before signing off a development, three questions are enough:
- Can the standard cover this need with different configuration?
- Can the process be simplified rather than reproduced?
- What is the total cost of this development over five years, version upgrades included?
If the three answers are not documented, the decision is not ready.
