Why I only take one client
at a time.

The stock advice for solo consultants is to run multiple clients in parallel. Diversify your income, hedge against any one project going sideways, keep the pipeline warm. It sounds reasonable. It is also, in my experience, the single biggest reason solo consultancies produce mediocre work.

When you are running three projects at once, your brain is not running three projects at once. It is running one project, badly, while two others rot in the background. Context-switching has a real cost — well documented in research, and obvious if you have lived it. Every switch costs minutes of recovery time, sometimes more, and the quality of the work that comes out of those fragmented hours is materially worse than the work you do in a long uninterrupted block.

Here is the bit nobody talks about. The cost of context-switching is paid by the client, not the consultant. The consultant still bills their hours. The client still pays. But the work the client receives in those fragmented hours is slower, buggier, and less thoughtful than it would have been if you had been heads-down on it.

Multi-client engagements are an arbitrage where the consultant captures the upside of utilisation and the client absorbs the downside in quality. Once I noticed that, I could not unsee it.

I made the switch about two years ago. The differences are larger than I expected.

The work is dramatically better. When you are inside one problem all day, every day, for weeks, you start seeing it from angles you would never see in a fragmented schedule. Architectural decisions get made with the full picture in mind. Edge cases surface. You have time to write the code well, instead of writing the first thing that compiles.

The relationship is dramatically better too. The client knows I am thinking about their problem. They get fast responses, because I am not triaging across three Slack workspaces. I get fast answers, because they trust I am not leaking their context to other projects.

Pricing gets simpler. Single-client engagements are scoped and fixed-price by default. There is no incentive to drag work out, no debate about which hours belonged to whom, no timesheet theatre. We agree what good looks like, I deliver it, we close.

The obvious objection: what if the client cancels? Yes, that is a risk. I manage it by being honest about my pipeline. I tend to be booked one or two projects ahead, with a clear “next project starts when current project ends” arrangement. The waiting list is the diversification.

The other objection: what if there is downtime in the project — waiting for client review, waiting for an external dependency? Real projects always have these gaps. I use them deliberately. That is when I write public posts, work on open source, and read deeply. The downtime stops being dead time and becomes the time I invest in the next year of work.

And finally: am I leaving money on the table? Possibly. Theoretically I could double my throughput by running two projects. In practice, the work would be worse, the clients would be unhappier, and my reputation — the actual long-term asset — would be eroding. Throughput is not the metric.

There is a regime where this falls apart. If you are early in your career, you may need the variety of multiple clients to learn faster. If you do quick interventions — audits, half-day workshops, fast turnarounds — single-client makes no sense.

But for the kind of work I do — building software end-to-end, over weeks or months — going deep is the only honest way to do it. Every client I take is the only client I am taking. They get all of me. That is the deal, and that is why it works.