ERP Customisation vs Out-of-the-Box: When Customising Pays for Itself

Every ERP project reaches the same moment. Someone demonstrates the standard workflow, and someone else in the room says: that is not how we do it.

What happens next determines the total cost of the system more than any other decision in the project — more than the platform choice, more than the licence model, more than the implementation partner's day rate.

The question that actually matters

The instinct is to ask whether the software can be made to match the process. The answer is almost always yes. That is the wrong question.

The right question is: why does the process work this way?

There are two good answers and one bad one.

Good answer one: because it is a genuine competitive advantage. A costing model your competitors have not worked out. A service commitment your customers buy you for. A way of sequencing work that is faster than the industry norm. Customise. This is the part of your business worth encoding in software.

Good answer two: because a regulator requires it. Statutory report formats, sector-specific returns, tax treatments particular to your trade. You do not get to negotiate with a compliance requirement. Customise.

The bad answer: because that is how we have always done it. This is where most customisation requests come from, and it is where most ERP technical debt originates.

The cost you do not see at quotation

A custom module has a purchase price and a carrying cost. The purchase price appears in the quote. The carrying cost does not.

Carrying cost includes:

• Regression testing that module on every platform upgrade
• Re-explaining it to each new person who joins the team
• The constraint it places on future changes elsewhere in the system
• The specific individual who understands it, and what happens when they leave

None of this is visible in year one. All of it is obvious in year four. When someone says "we cannot upgrade because of the customisations", this is the bill arriving.

Upgrade-safe versus upgrade-blocking

Not all customisation carries the same risk. The technique matters enormously.

Upgrade-blocking: modifying the platform's core source code. The change works. It also means the next security patch or version release cannot be applied cleanly, because applying it would overwrite the modification. Teams in this position usually stop upgrading, and then the problem compounds quietly for years.

Upgrade-safe: building the same functionality as a separate, loadable unit that sits alongside the core. On iDempiere this is an OSGi plugin bundle. On ERPNext it is a separate Frappe app. The core updates independently; your extension keeps working, or fails loudly in testing where you can fix it.

The functional result on day one is identical. The difference appears on the day a critical patch is released, and by then the decision has already been made for you.

If you have inherited a patched-source system, it can usually be re-packaged into proper extensions. That is a discrete piece of work with a clear before-and-after, and it is worth quoting separately rather than living with the constraint indefinitely.

A practical test before approving a customisation

Before signing off any custom development, work through these:

1. What does standard functionality actually do here? Not what someone assumed — what it does when configured properly. A surprising share of customisation requests dissolve at this step.
2. What breaks if we adopt the standard behaviour? Quantify it. If the answer is "people would need to adjust", that is a training cost, not a development cost.
3. Is this a competitive difference or a statutory requirement? If neither, the default should be no.
4. Can it be built as an extension rather than a core change? If not, understand precisely why before proceeding.
5. Who maintains it, and is it documented? A customisation only one person understands is a liability with a name attached.
6. What is the five-year cost, not the build cost? Include upgrade regression testing in the estimate.

Phasing beats deciding everything upfront

A useful pattern: go live on standard functionality, run it for one full business cycle, then revisit the customisation list.

Two things reliably happen. Some requests disappear, because the standard approach turned out to be fine once people used it rather than imagined it. And the requests that remain get sharper — specified by people who now understand the system, rather than by people describing their old one.

The requests that survive that filter are usually worth building. The ones that do not survive it would have been maintained forever.

Ownership is part of the trade

If you do customise, own the result. Source code, technical documentation, configuration notes — delivered to you, not held by the vendor.

This is not distrust. It is what makes a future vendor change a knowledge-transfer exercise instead of a re-implementation. It is also, bluntly, a reasonable test of a partner: a firm that resists handing over code you paid for is telling you something about how it intends to retain you.

At SyvaSoft, customisation is built as OSGi plugins or separate Frappe apps, and the source is delivered to the client. Not because it is generous, but because a customisation you cannot maintain without us is an asset on our balance sheet and a liability on yours.