> ## Content Index
> Fetch the complete content index at: https://www.etrminsider.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Build, buy, or extend: the honest economics of ETRM customization
- URL: https://www.etrminsider.com/build-buy-or-extend-etrm-customization/
- Published: 2026-10-14T08:02:55.000Z
- Updated: 2026-10-14T14:02:58.000Z
- Description: Customizations are how today's ETRM becomes tomorrow's replacement project. A simple order of preference, a rough five-year cost model, and the signs you've crossed from extending into owning a fork.
- Author: Emmanuel Gonzalez
- Tags: ETRM, Vendor Guides

**Independence:** ETRM Insider is vendor-independent. This article names no preferred products, and no vendor sponsored, paid for, or reviewed it. [Our standards →](https://www.etrminsider.com/standards/)

Nobody sets out to fork their ETRM. It happens one reasonable request at a time. A trader needs a deal type the product doesn't handle. Settlements needs a calculation the vendor won't build this year. Each change makes sense on its own. Five years later the upgrade estimate looks like a reimplementation, and someone starts a replacement project.

That's how customization becomes the next replacement project. The fix isn't "never customize." It's knowing which kind of change you're making, and what it will cost you every year after go-live.

## The order of preference

When the business asks for something the system doesn't do out of the box, work down this list and stop at the first option that works.

**1\. Configure.** Use the product's own settings, reference data, rules, and reporting tools. Configuration usually survives upgrades because the vendor supports it. If it can be done this way, do it this way, even if it's less elegant.

**2\. Extend through supported interfaces.** Use the vendor's published APIs, extension points, scripting, or event hooks. The vendor has committed to keeping these stable, or at least to telling you when they change. Your extension lives outside the core and talks to it through a contract.

**3\. Build at the edges.** Put the specialized logic in a separate component (a pricing service, a reporting layer, a data platform, a workflow tool) that reads from and writes to the ETRM through supported interfaces. You own it, but it doesn't touch the core, so an upgrade doesn't break it.

**4\. Fork the core.** Change the vendor's code, database schema, or internal processing directly. Don't. Once you do, every upgrade becomes a merge project, the vendor's support gets conditional, and you own a version of the product nobody else runs.

The test for each request: *if the vendor shipped a new major version tomorrow, what would we have to redo?* For configuration, very little. For a fork, possibly all of it.

## A rough cost model

The decision usually gets made on build cost alone. That's the smallest part of the bill. A useful model has four lines, estimated for each change:

- **Build:** design, development, and testing to get it into production.
- **Run:** support, monitoring, fixes, and the people who understand it.
- **Upgrade tax:** the work to retest, and often rework, the change every time the core system is upgraded.
- **Opportunity cost:** upgrades you delay or skip because of it, and the vendor features you can't adopt as a result.

Here's an illustrative five-year example. The numbers are made-up round figures to show the mechanics, not a benchmark. Plug in your own.

Say a settlement calculation can be delivered two ways:

**Option A, an edge component through supported APIs.** \- Build: $150k. - Run: $30k a year, or $150k over five years. - Upgrade tax: one regression test cycle per upgrade, two upgrades in five years at $20k each, $40k. - **Five-year total: $340k.**

**Option B, a modification to the core.** \- Build: $100k. It's cheaper up front because you skip the interface work. - Run: $40k a year, or $200k over five years. It needs people who know both your change and the vendor's internals. - Upgrade tax: rework and retesting on each upgrade, two upgrades at $120k each, $240k. - **Five-year total: $540k.**

The cheaper build ends up costing more. And that's before the opportunity cost: if the upgrade tax is high enough, upgrades get deferred, and you lose vendor fixes and features. That's the cost that eventually justifies a replacement.

The point isn't the specific numbers. It's that the upgrade tax is recurring and grows with every core modification, while the build cost is paid once.

## Signs you've crossed from extending into owning a fork

Watch for these. Any two of them together should be a steering-committee topic.

- **Your upgrade estimates are dominated by retesting and reworking your own changes,** not by the vendor's new features.
- **You're more than one major version behind,** and the reason is your customizations.
- **The vendor's support team asks which of your changes are involved** before they'll look at an issue.
- **Only one or two people understand a critical change,** and they're contractors or close to leaving.
- **You have database triggers, stored procedures, or scheduled jobs writing directly to the vendor's tables.**
- **Nobody can produce a current list of every customization,** with an owner and a business reason for each.

## Keep a customization register

The cheapest control is a list. For every change beyond configuration, record:

- what it does, and the business reason it exists;
- which option it is (extend, edge, or core);
- the owner on the business side and the owner on the technical side;
- the interfaces or tables it touches;
- the date it was last tested against an upgrade;
- whether it can be retired if the vendor now offers the capability.

Review it before every upgrade and at least once a year. Every review should retire something. Vendors add capability over time, and changes made years ago are often no longer needed.

## Deciding on a new request

When the next request lands, ask four questions in order:

1. Can we change the process instead of the system?
2. Can we configure it?
3. If not, can we build it outside the core using supported interfaces?
4. If it has to touch the core, what's the five-year cost, including upgrade tax, and who signs off on owning it?

Make whoever asks for a core change sign off on the upgrade tax, not just the build cost. That one rule changes the conversation.

## Use it this week

Start the register. List every customization you know about and mark each as configure, extend, edge, or core. Count the core ones. That number is the best predictor I know of how painful your next upgrade will be.

---

*Drafted with AI assistance from my research notes and outline; reviewed, edited, and fact-checked by me. The opinions are mine.*