The Second Client Problem

Every service business begins the same way, and the problem is that the beginning works.

You do something well for one client. A second client wants the same thing. The obvious move, and on that day with that information the correct one, is to copy what you built for the first and edit the copy. It takes an afternoon instead of a week, the client is delighted, and you have doubled revenue at almost no marginal cost. It feels like the leverage everyone promises you.

Do it eight more times and ten near-identical versions of the same logic are running in ten places, diverging, and a fix to one reaches none of the other nine. The bug you patched for client three is still live for clients one, two, and four through ten, and you will find out which when one of them calls. The margin that looked like it was compounding has been converting into maintenance, and the fix now costs a migration performed on live systems belonging to people who are paying you.

I have watched this happen from the inside more than once, and no single decision in the sequence was wrong.

The trap is that the wrong answer keeps working

That is what makes it a hard problem rather than a stupidity problem. If copying failed at client two, nobody would do it. It fails at client ten, and by then copying is no longer a choice you are making but the shape of the business.

Every incentive points the wrong way at the moment the decision matters. At client two, building the general version costs a week you do not have, to solve a problem you do not yet have, for clients you have not yet won. The general version has no advocate in the room. The specific version has a delighted customer and an invoice.

The correct decision requires acting on a problem that is still theoretical, with time that is scarce, on evidence that will not arrive for a year.

What building it early costs

I tested this on myself, which is the useful thing about being small enough to be your own experiment.

Before I had a single client, I built the general version: a registry with one row per client, holding their configuration — status, where their work should run, which credentials to use, where their alerts go — and one small resolver that every client-facing process calls first to find out who it is serving and whether it is allowed to. There is no client-specific logic anywhere else. A new client is a new row.

It cost a few days that produced nothing demonstrable, with no client asking for it and no revenue attached. It felt like procrastination dressed as architecture until it did not.

What the few days bought is narrow: I can take a second client without touching what the first one is running. It is not a platform, it does not scale to a thousand tenants, and it will need rework at a size I am nowhere near.

What it does is move the expensive work from during the relationship to before it. The plumbing costs the same either way. What changes is whether you pay for it in quiet days now or in a live migration later, with a customer watching.

The version of this that is not about software

I think this generalizes past automation to how a practice becomes a business.

A practice sells the same expensive judgment repeatedly. It scales with the practitioner’s hours and stops when they do. A business sells something that was built once. The transition between the two is this decision, made a hundred times in small ways: when the second client asks for what the first one got, do you copy or generalize?

You should copy at client two, and probably at three. Generalizing too early is its own failure: you build the abstraction before you know which parts vary, and an abstraction built from one example is usually wrong about which axis matters. There is no virtue in a chassis designed for requirements you invented.

But somewhere around the third or fourth time there is a window, when you have seen enough variation to know what differs and not yet made enough copies to make the fix expensive. It is narrow, it does not announce itself, and it closes while you are busy delivering.

The only reliable signal I have found is irritation. When you notice you are making the same edit for the second time and resenting it, the window is open. That resentment is the cheapest available signal that something should be a row in a table rather than a copy of a file.

Most people feel it and keep copying, because a client is waiting and the copy takes an afternoon. That afternoon, repeated, is how a practice fails to become a business.