Insights / Article / Enterprise software implementation
ArticleThe true cost of software customisation
Every custom feature adds testing, support and upgrade cost for years. The initial build is only the start of what you pay.
A customisation request usually arrives with a modest price tag. A developer estimates a few days to add a field, adjust a screen or automate a calculation, and the business agrees it is worth it. Multiply that by fifty or a hundred requests over a project, and the organisation has quietly committed to a cost that will follow it for as long as it runs the system.
Every custom feature adds testing, support and upgrade cost for years. The initial build is only the start. Understanding the full cost does not mean refusing all customisation. It means making each decision with the real price in view.
What the build estimate leaves out
Build estimates cover the effort to write and unit-test the code. They rarely include the work that surrounds it, during the project and long after. Include testing, documentation, support and upgrade work, not only the build.
- Design and specification: workshops, documents and reviews to define what the change should do.
- Testing: functional testing, integration testing with other parts of the system and regression testing whenever anything else changes.
- Documentation: technical notes for future developers and user guidance for the people who rely on it.
- Support: investigating and fixing issues, often by someone who did not write the original code.
- Upgrades: checking, adapting and retesting the customisation every time the vendor releases a new version.
- Knowledge risk: if the person or partner who built it leaves, the cost of understanding it again.
Taken together, these costs often exceed the original build several times over across the life of a system. The exact multiple varies, but the direction does not: the longer a system runs and the more often it is upgraded, the more each customisation costs.
An illustration
Picture a mid-sized manufacturer that adds a custom screen for entering production orders, because the standard screen asks for information in a different order. The build takes a week. Over the next five years, the screen is retested at every quarterly update, breaks twice when the vendor changes an underlying table, needs a fix when a new product type is introduced and has to be explained to every new planner, because the standard training material does not cover it. When the developer who built it moves on, the next partner spends days working out how it functions before they can change it.
None of these events is dramatic. Together, they cost many times the original week, and the business gained little that a short training session on the standard screen would not have delivered.
Why upgrades are where the cost bites
Modern enterprise platforms release updates frequently. Cloud ERP and SaaS products may update several times a year, and on-premise systems still have major versions every year or two. Each update is a chance to gain new features and security fixes, but only if the system can absorb it.
Heavily customised systems struggle. Every custom module must be checked against the new version, adapted where the underlying product has changed and retested. Organisations in this position often delay upgrades, which leaves them on older versions with fewer features, more security exposure and an even bigger jump when they finally move. A typical outcome is a system that was modern at go-live and feels dated within a few years.
Prefer configuration
Settings and standard options cost less to carry than code. Most modern platforms offer a wide range of configuration: workflows, approval rules, custom fields, report builders, automation tools and low-code extensions supported by the vendor. These are designed to survive upgrades, because the vendor maintains the framework they sit on.
Before approving any custom code, ask three questions in order. Can the standard process meet the need if we change how we work? Can configuration meet it without code? Can a vendor-supported extension or marketplace module meet it? Only if all three answers are no should custom development be considered.
A simple approval rule
Require every customisation request to state the business value, the lifetime cost estimate and why configuration or process change will not work. Have a senior business owner sign it. Many requests are withdrawn at this step.
When customisation is worth it
Some customisation is justified. The question is where. Good candidates tend to share one or more traits.
- The process genuinely differentiates the business and protects significant revenue or margin.
- A legal or regulatory requirement cannot be met by standard features.
- The cost of changing the business process would clearly exceed the lifetime cost of the code.
- The change is small, well bounded and unlikely to conflict with future product updates.
Requests that rest on habit, on replicating a familiar screen from the old system or on a preference of one team are rarely worth the lifetime cost.
Keep customisations small and documented
Where customisation is justified, the way it is built matters as much as the decision to build it. Isolate changes so upgrades remain straightforward.
- Build extensions using the vendor’s supported extension methods rather than altering core code.
- Keep each customisation focused on one purpose, with clear inputs and outputs.
- Maintain a register of every customisation: purpose, owner, technical location and test cases.
- Write automated tests where possible, so regression checks at upgrade time are quick.
- Store code in version control with clear history, even for small changes.
Review what you already have
Many organisations carry customisations that are no longer needed. The standard product may have caught up, the process may have changed or the team that asked for it may no longer exist. Review the customisation register at least once a year, and before every major upgrade. Retiring a customisation that the product now covers is one of the cheapest ways to reduce the cost of running a system.
If you are mid-project, start by adding a lifetime cost line to every open customisation request and asking for senior sign-off. If you are running a live system, build the register and identify the ten customisations that cause the most effort at upgrade time. Those are where the savings lie.
Source: Intelliversal analysis.
