Every Customer Name in Your Code Is a Product Decision Made by a Deal.

Watch the video version:

Years ago, on a consulting assignment, I inherited a code base with a switch statement on customer names. Dozens of them, hardcoded, one case per customer, and every other customer fell into an else statement. Most of the branches were very close, codewise. Most carried only a slight variance that could have been parameterized and set up as configuration. I had to laugh. Then I was very happy it was outside my scope. It was not why I was brought in, so I did nothing about it.

That last part is how a switch statement like that survives. I was one more person who saw it, laughed, and went back to my own job. Everyone who sees it has a different job to do. Nobody who could remove a branch is responsible for the product as a whole, and the people responsible for the product as a whole rarely read that file.

Epic's own keynote at Open@Epic put a number on the pressure that builds those branches. In 2025 its team "received 75,000 requests" for new integration capabilities, and "bespoke one-off solutions to solve each one of those requests is just not sustainable or practical." Later that afternoon, a speaker from Children's Hospital of Philadelphia described what happens to an app built around one site's setup when it moves to the next: you build a "rocket ship" at one hospital, and at the next site you have a jet, then a car, "and then eventually you're just walking again." His fix was building configuration in so the app could fit each site's local practice.

The switch statement has a playbook behind it: win the customer first and clean up later. A large customer asks for something only they need, it is only a few lines, and the deal already promises it, so a branch with that customer's name goes in and someone plans to generalize it someday. Someday never comes, and the next customer gets a branch of their own. The opposite playbook, standards only and the customer adapts, fails the other way, because flexibility matters to the people using the product.

Two legitimate demands meet at every customer request: fit this customer, and serve the whole user base. Both are right, and neither will ever fully win. That is a Structural Bearing™, the term I use for a tension between two legitimate systems that never resolves and only gets managed. A hardcoded branch settles that tension in the customer's favor, quietly, in a place only engineers can see. Each branch looks reasonable on the day it is written. That is how Creep works: no single concession is the problem, and the problem is only visible when you hold this year's code next to the code from three years ago.

The cost lands on every change that follows. A fix or an upgrade has to be checked against dozens of branches, and the next customer gets a copy of the closest branch with a tweak. Whatever falls into the else statement becomes the real product, and nobody owns it. The product's boundary moves one deal at a time. Engineering capacity goes into maintaining variations instead of features every customer can use, and onboarding a new customer becomes a code change only an engineer can make.

The way to manage it is to stop letting each deal settle the tension and design the interface instead: features the customer maintains settings for. I build for all the customers, never one, and every request starts with one question. Will this be useful to our user base? If it will, build it once as a configurable feature for everyone. If a customer needs help configuring it, support can do that, and the hand-holding gets built into the price. I have charged setup or onboarding fees on the SaaS applications I am responsible for. It is common practice. If a request is truly narrow, or takes the product outside its reason for existing, I reject it. What never goes in is a branch with a customer's name on it. You can hold that line starting with the next request, without touching a single branch that already exists.

Search your codebase for the names of your three largest customers and count the hits. Each one is a decision about what your product is, made by a deal rather than by anyone deciding. Then ask the harder question: who in your organization is currently allowed to decide that a customer gets their own branch?

The Edge Case walks through Constraint Architecture™, the method for mapping a tension like this one precisely enough to stop fighting it and start designing the interface: https://TheEdgeCaseBook.com

Six tensions your best design will never resolve, and why the organizations that manage them well stopped trying to solve them.