Keep the rules out of the code and one program serves any number of customers.
I’ve always thought hardcoded customer rules are among the laziest decisions a software team can make, and among the most expensive. They feel fast in the first month. Then every new customer turns into a small act of surgery on a system nobody wants to touch, and the people who pay for it are the engineers stuck maintaining it and the customers stuck waiting.
What does it mean when software integrates with everything?
The claim usually means the connection works.
Connection is the part vendors show, because connection is the part that demos well. Data goes out of one system and arrives in another. Everybody nods.
The connection was never the hard part. The hard part is that the receiving system wants the data arranged its own way, on its own schedule, with its own exceptions, and the next customer wants something different. Multiply that by every customer you have and you have the actual project. Nobody sells you that half.
I don’t trust any vendor whose demo ends at the connection. The part they skip is the part that eats the budget, and the buyer usually finds that out after the contract is signed, when the change orders start arriving for every customer who wants something slightly different.
How do you build software that handles hundreds of different customers?
In the early 1980s I led a project for a company called National TV Log, and their entire business model depended on solving that problem.
The idea was clever. Reach into a newspaper’s computer, take the file, insert small boldface advertisements into it, and put the newspaper back. Fully automated, no humans in the middle.
I’ve always thought hardcoded customer rules are among the laziest decisions a software team can make, and among the most expensive.
Around four hundred newspapers, each dialed up over a modem, because modems were what existed. Grab, insert, return, hang up, move to the next one. Then the part that made it real work. Every newspaper had its own rules about where the advertisements went and how they were formatted. Four hundred customers, four hundred sets of rules, no two the same. Every one of them wanted the advertisements handled their own way.
Why does per-customer configuration break software projects?
Because the obvious solution scales terribly and nobody notices until it’s too late.
The obvious solution is to handle the differences in code. The first customer is easy. The second is easy. By customer five you have branching logic. By customer forty you have a system nobody can safely change, because every change risks all forty. That’s the ceiling, and it arrives without warning.
Teams reach customer forty faster than they expect and the problem arrives fully formed. Nothing about it is gradual.
The modern version hides behind better words. Per-tenant configuration. Customer-specific business logic. Feature flags. Same problem, and the same teams hardcode the first three customers and discover it at the fortieth.
New words don’t change the damage. A feature flag with a customer’s name baked into it is the same trap with better marketing, and I think teams fall into it because nobody on the project gets rewarded for thinking about customer forty on the day customer three is signing.
Where should business rules live in a system?
Outside the code, in something a person can read and change without a developer. That’s what we did. The rules for all four hundred newspapers lived in a table, and the program read the table.
Building that table wasn’t trivial, because we had no database to put it in. No structured query language, no commercial database engines available to us. We built the table and everything around it ourselves. With no tools and no prior art, the design was still right. One program, and adding a newspaper meant adding a row and not writing code. Four hundred was what they happened to have. The design had no number in it at all.
Teams today have databases, configuration structures, and rules engines available for free, and a great many of them still put the customer differences in the code.
That one is a bad habit. The tools we had to build from scratch are sitting right there, free, and teams still write the rules into the code because it’s quicker this afternoon. The developers who inherit that code a few years later are the ones who pay for it, and they didn’t make the choice.
How do you know when to move logic out of code?
Three signals, and any one of them is enough.
The first is a conditional statement that names a customer. The moment code says if this is customer Jones, the rules have leaked into the wrong layer.
The second is a deployment required to onboard a customer. If adding a customer means shipping code, every new customer carries the risk profile of a release.
The third is a change nobody wants to make. When a small adjustment for one customer requires regression testing everybody else, the differences are entangled with the logic.
Any of those three means the rules need to come out. Doing it at customer five is a morning of work. Doing it at customer forty is a project.
| Signal | What it means |
|---|---|
| A conditional statement names a customer | The rules have leaked into the wrong layer |
| Onboarding a customer requires a deployment | Every new customer carries the risk profile of a release |
| A small change for one customer needs regression testing for everyone | Customer differences are entangled with the logic |
What happens when a consultant does the job too well?
The code was finished and delivered, and the system worked well for them.
Then somebody from my team took a job at National TV Log and took the work over. We lost the account. That outcome is fine. They got a good product, it did what they needed, and the person who understood it best was now inside their building instead of billing them.
A consultancy that builds something durable and documents it properly will sometimes lose the work to its own success. The alternative is staying indispensable by leaving the thing half explained, which is worse for the client, worse for the person doing it, and worse for the firm in the long run. Anyone hiring a consultant should ask what happens when the engagement ends. A good answer describes how the knowledge transfers. A bad answer explains why you’ll always need them.
I don’t respect consultants who make themselves permanent by keeping the work murky. It’s a quiet way of taking money from a client who trusted them, and the client is the one left stranded when that consultant finally leaves.
My take
Customer rules belong in a table. Hard-code them and every new customer means a code change and a deploy. We built one program for four hundred newspapers in the early 1980s with nothing off the shelf, and adding a customer meant adding a row. You’ve got free databases and rules engines today, so there’s no excuse. If your code names a customer or onboarding needs a deploy, move the logic out now.
What can a 1980s integration project teach a modern team?
The system did its job. Four hundred newspapers, automated, running on rules in a table nobody had to compile.
None of the technology matters now. The modems are gone, the file formats are gone, the company is gone.
What survives is the decision that removed the ceiling. The rules didn’t live in the program. They lived in a table, and the program read the table, so the number of customers stopped being an engineering question.
Every platform sold today can do that. Most teams still don’t, because the first three customers don’t need it and by the time the fortieth arrives the code has already made the choice for them.
It frustrates me that teams with every tool in the world still have to relearn a lesson we worked out with modems and a homemade table. Putting customer rules in the code is a choice, and the teams that keep making it are choosing a ceiling for their own company.
