A request arrives during an implementation: the standard object does not quite fit, and a custom field with a bit of logic behind it would solve it. It takes an afternoon. Everyone agrees, and it goes in.
The afternoon is the smallest part of what that decision costs, and the rest of it arrives on a schedule nobody is in the room for.
Where the cost actually lands
Salesforce releases three times a year. ServiceNow releases twice. Every one of those releases is an event for every piece of custom logic you own.
Each customisation carries recurring cost in:
- Regression testing at every platform release, indefinitely
- Remediation when a release changes behaviour the customisation relied on
- Onboarding — every new administrator has to learn it, and it is not in the vendor documentation
- Blocked native features, when the vendor later ships something that conflicts with it
- Migration cost, if you ever move platform or consolidate instances
None of these appear in the estimate for the afternoon of work. All of them are paid by a different team, in a different budget year.
The four-question test
Before agreeing to custom code, four questions settle most cases:
- 1Is this a genuine business requirement, or a preference inherited from the previous system? A surprising proportion of customisation requests are attempts to reproduce something the old tool did, not something the business needs.
- 2Has the vendor shipped, or announced, something that covers this? Building six months before a native feature arrives is a cost you pay twice.
- 3Can the process change instead? Sometimes the cheapest configuration change is to the process rather than the platform.
- 4Who will own this in three years, and how will they know why it exists?
When custom is genuinely right
This is not an argument against customisation. Some requirements are genuinely specific to how a business competes, and configuring around them produces something worse than the custom build would have been.
Custom code is usually justified when:
- The requirement is core to how the business differentiates, not to how it administers itself
- The configuration workaround would be more complex than the custom solution
- The business value is large enough to absorb the recurring upgrade cost
- There is a clear owner who will maintain it
Document the decision, not just the code
Whenever you choose custom, record why — the requirement, the alternatives considered, the reason configuration was insufficient, and who decided.
Three years later, someone will be looking at that code during an upgrade, deciding whether it can be removed. Without the reasoning, the safe choice is always to keep it and test around it, which is how platforms accumulate logic that nobody can justify but nobody dares delete.
A decision log is a few paragraphs at the time. It is the difference between a platform that can be simplified later and one that only ever grows.