The customization ladder: Why platforms scale and bespoke integrations don't

Enterprise software becomes difficult to scale when every customer difference turns into bespoke code.

Every enterprise eventually produces the same sentence:

"We're a bit different."

Different content models. Different approval processes. Different markets. Different legacy systems. Different compliance requirements.

Those differences are inevitable. The challenge is deciding where they belong.

This article explores the four levels of customization that let platforms adapt to real-world enterprise complexity while keeping the core scalable.

The trap in "we just need to connect X"

Every integration starts with the same sentence:

"We just need to connect our CMS to the TMS."

It sounds like a small, contained problem. A dedicated integration solves it quickly.

That's exactly the trap.

One integration is easy to understand. Ten means ten authentication implementations, ten retry mechanisms, ten error-handling patterns, and ten things to update when an API changes.

The cost compounds quietly.

Every new connection adds another piece of code to maintain. Every exception adds another dependency. Every customer-specific requirement creates another thing to test, support, and eventually explain.

The integration layer becomes the slowest, most fragile part of the program.

The bigger question is how many differences your platform can absorb without becoming a collection of bespoke versions.

That depends on where customization lives.

What a platform actually buys you

An integration platform builds the shared plumbing once and lets every connection inherit it: authentication, transport, retries, monitoring, versioning, and error handling.

When the platform improves, every connector benefits. When a fix ships, it ships everywhere. Connector versions can run side by side, so one customer's upgrade doesn't force another's.

That's useful.

The real scaling challenge appears when someone says:

"Our process is different."

A scalable platform needs somewhere for those differences to go.

• Some belong in configuration
• Some need workflows
• Some belong in extensions
• Some should become product capabilities for everyone

Problems begin when every difference becomes core code.

That's how platforms accumulate complexity.

The customization ladder

The ladder is simple:

Configuration → Workflow → Extension → Core

The further a customization moves toward the core, the more it becomes part of the platform everyone has to carry.

The goal is to put each type of customization in the right place.

1. Configuration

If it's a setting, it’s a template.

Routing, language pairs, content selection, notification rules, and other predictable variations belong in configuration.

Take a global enterprise that routes content differently depending on business unit, source language, and workflow type.

Instead of coded logic, the connector resolves a routing table: each combination looks up the right project template and tagging automatically.

When the organization restructures, an administrator edits the table. No engineer is involved, nothing is redeployed, and the change is live in minutes.

2. The workflow layer

If it requires business logic, compose it inside guardrails.

Some content flows are genuinely complex. They span systems, contain conditions, transform data, and need logic that no configuration template can express.

That's what the workflow layer is for.

Consider a marketing organization publishing from two systems: product content from a PIM and campaign pages from a CMS.

The flow pulls from both, combines the relevant product and terminology context, routes output through different review steps for different markets, and returns each piece to its source system with its structure and metadata intact.

That entire bridge is composed in the workflow layer. And because it lives inside the guard-rails, platform upgrades never break it.

3. The extension layer

If it's genuinely niche, keep it outside the core.

Some requirements are real but rare.

One customer. One industry. One legacy system. One piece of infrastructure that nobody expects to see again.

Those requirements deserve a supported home, while keeping them separate from the shared platform.

That's the extension layer.

Customers and certified partners can build more freely using open interfaces, without their code entering the platform core.

Imagine a customer running a decades-old, home-grown document management system that no vendor will ever build a standard connector for.

A partner can build the bridge on the extension layer. It speaks to the legacy system on one side and the platform's open interfaces on the other.

The customer gets the integration they need. The rest of the platform remains insulated from it And then that legacy system eventually disappears, the extension is simply switched off.

4. The core

Never customize the core for one customer.

A customization inside the platform core creates a fork. And every fork becomes another platform to maintain.

However large the deal, however urgent the quarter, the core should remain shared.

That doesn't mean rejecting the requirement. It means finding the right home for it.

For example, a request arrived recently that none of the three rungs can hold. The platform itself needed to behave differently for one account.

Saying yes once would have created a private branch of the product, meaning every future release tested twice, every incident diagnosed twice. Instead the request should be treated as what it really was: evidence of a missing product capability.

Instead, it went onto the roadmap as a feature for everyone, and shipped as configuration (rung one) a release later.

This way, the customer got a supported capability instead of a fragile exception.

How to tell where a customization belongs

The ladder is also a decision framework.

When someone asks for a new integration behavior, ask four questions:

The answer won't always be obvious. That's where discipline matters. A scalable platform needs someone who can look at a request and say:

"Yes, we'll solve that. It belongs here."

How XTM Connect puts the ladder into practice

The customization ladder is the principle behind XTM Connect, XTM's integration platform for connecting enterprise content systems, localization workflows, and translation technology.

XTM Connect provides the shared infrastructure for authentication, data transfer, monitoring, error handling, and connector management, while giving each customer controlled ways to adapt how those connections work.

Predictable differences can be handled through configuration. More complex business logic can be composed through workflows. Customer-specific or legacy requirements can be handled through extensions and open interfaces. The core platform remains shared.

That separation matters as the number of systems and customers grows. A new requirement can be accommodated without turning it into another bespoke integration that has to be maintained forever.

The result is a platform that adapts to how enterprises actually work, without asking the platform itself to become bespoke.

Why this matters more in the AI era

The ladder was designed for scaling human demand. It turns out to be exactly the structure the agentic era requires.

AI agents are becoming users of localization platforms: creating projects, running analysis, retrieving translations through services rather than screens. And increasingly they will be builders too, composing workflows and extensions on demand.

A platform with no discipline about where change lives cannot safely let an agent touch anything. A platform built on the ladder can. Agents configure templates like power users, compose flows inside workflow guard-rails, build on the extension layer like partners — and are refused at the core like everyone else.

The rungs that keep a hundred customers from destabilising each other are the same rungs that keep a thousand agents from destabilising anything at all.

Dedicated integrations optimize for the first customer. Platforms optimize for the hundredth. And the ladder is the entire difference.

So where does customization happen in your integration stack?

And perhaps more importantly: Who's allowed to say no?