Code for logic, data for parameters

Over the years, one of my products had collected a lot of customer-specific integrations: a file import for one customer, an HR system sync for another, a custom export for a third. Each was built as its own code, which meant dozens of slightly different versions to maintain. The goal was one shared framework where adding a customer integration is a small, contained piece of work, never another copy.

The tempting design

Claude’s first proposal was elegant on paper. Describe each customer’s integration entirely as configuration: which columns map to which fields, which rules apply, all stored as data. No code per customer at all.

I said no. I have seen where that goes. Every customer has one odd rule, and the configuration grows a new switch for it. Then another. Eventually the configuration is a programming language, just a worse one, with no tests and no way to read it.

What we built instead is a small class per customer, each following the same four steps: download, read, map, import. The shared framework handles everything common. Each customer’s class only says what is different about them. Configuration is kept for the things that genuinely vary by setting: which folder, which schedule, which credentials.

Code for logic, data for parameters.

Where the line paid off

A week later we connected the first customer whose data came from an API rather than files. The question came up whether the admin form should ask for the endpoint addresses. The same line answered it. That customer’s integration is already code, so its wiring belongs in code. The form shrank to a username and an API key, which is all an account manager should need to know.

The other half

Claude made the first slice possible by exploring before designing. Half of what we needed already existed in the codebase: a bulk upload engine, file storage helpers, an email sender, a scheduler. The design became mostly reuse.

But the most valuable corrections were not technical. They were things only I could know about how customers actually work: multiple folders with different naming, “latest” meaning the date in the filename rather than when the file arrived, only sending changes that are real. They only came out once there was a working slice to react to.

So the other lesson is speed. Build a thin, real version early, because that is when the knowledge in people’s heads finally shows up.