Main idea

A feature needs a new column in the database. If the database lives on the customer's side and every production release means sending a procedure to their team, waiting for approval, booking a maintenance window and manually checking that the migration went through, then delivery no longer depends on the vendor.

The consequence is not just delay. One customer applies the migration on Tuesday, another waits until Friday, a third postpones to the following month. You end up with several versions of the engine, several schema states, and complexity that grows with every release.

What is lost then is the structural advantage of the model: continuously evolving a single product shared by all customers.

Why it matters

The divergence isn't visible at the moment you accept the arrangement — the first customer is easy to serve. It shows up at the tenth, when every fix has to be tested against several schema states.

And the trend works against it: as delivery cadence rises, an architecture that demands a human intervention per customer for every change becomes that much more expensive.

Nuances and limits

The observation holds for structural changes. A configuration, a piece of content, a parameter can vary per customer without producing this divergence.

And there are models that deliberately accept multiple versions — software installed on the customer's premises. Those are different businesses, with different costs.

Open questions

• How many schema variants can a team carry before the cost of testing becomes prohibitive?