Over-customisation

Every customisation is a loan. It buys you exactly the behaviour you want today, and you repay it at every upgrade, forever.

That is not an argument against customising. It is an argument for knowing which loans are worth taking. Some customisations pay for themselves in a month; others exist because nobody wanted to have a difficult conversation about a process.

The three kinds, and how they age

Configuration. Fields, workflows, print formats, permissions — the things the platform is designed to let you change. These survive upgrades. Take as much as you need.

Extension. New doctypes and apps that sit alongside core, using documented hooks. These mostly survive, and break loudly when they do not. Reasonable debt.

Modification. Changing core behaviour — overriding a controller, patching a calculation, editing something you do not own. These break silently. The upgrade succeeds, the tests pass, and three weeks later a number is wrong in a way nobody connects to the release.

The taxonomy matters because teams talk about "customisation" as one thing while the cost differs by an order of magnitude between the first and the third.

The conversation that avoids most of it

When someone asks for a customisation, the useful question is not "can we?" It is "what happens if we do not?"

Sometimes the answer is a genuine cost — three people spending an hour a day, a compliance requirement, a customer commitment. Build it.

Often the answer is that a process would have to change, and changing it is uncomfortable but not expensive. That is a customisation bought with permanent maintenance to avoid a temporary conversation, and it is the most common kind of technical debt in ERP work.

Warning signs

- A customisation whose justification is "that is how we have always done it", with nobody able to say why. - Code that duplicates a standard feature because the standard one is *nearly* right. - Anything overriding a core calculation. Almost always a configuration or reporting problem wearing a code costume. - Customisation requested before go-live, for a process the team has not yet run in the new system. Most of these evaporate after a month of real use.

Repay deliberately

Keep a register: what was changed, why, who asked, and what breaks if it is removed. Review it at every upgrade. The value here is not documentation for its own sake — it is that "why does this exist?" has an answer two years later, when the person who asked has left and the only remaining evidence is code nobody dares delete.