The best system is the one you can give away

Being indispensable feels good. I want to start there, because an argument that opens by claiming immunity to a temptation is a weak argument.

There is a specific satisfaction in being the only person who can fix something. The message arrives at an inconvenient hour, you are the one who knows why the system behaves the way it does, and for a moment your value to the organisation is not in question. Every engineer has felt that. A great many consultancies have been built on it without anyone ever saying so out loud.

It is also the most expensive thing a client can buy without noticing they have bought it.

Dependency is a business model, not a service

An arrangement in which the supplier becomes more necessary the longer they stay is not a scandal. It is an incentive, and incentives do not require anyone to behave dishonestly in order to work.

You can see the shape of it in ordinary places. The retainer nobody can end, because ending it means finding out what only they know. The deployment process that lives in one firm’s runbooks. The codebase where getting a competing quote would require three months of onboarding before anyone could responsibly price the work. None of that is usually planned. It accretes. Every individual decision that produced it was defensible on the day it was made, and the accumulation is nobody’s fault and everybody’s problem.

The client rarely notices, because the system works. Dependency does not announce itself while things are going well. It announces itself on the day they want to change supplier, or the day the person leaves, or the day someone does diligence on the company and asks who can operate this.

What actually makes a system transferable

The usual answer is documentation, and the usual answer is not wrong so much as insufficient. I have inherited well-documented systems that were still opaque, and I have inherited sparse ones that I understood in a week.

The difference is what the documentation is of.

Code records what a system does. A test suite records what it is supposed to do. Both are recoverable by a competent stranger with enough time. Neither records why the system is the way it is, and why is the one thing a successor cannot reconstruct at any price.

An engineer inheriting a platform can read every line of it and still not know that the obvious approach was considered and rejected for a reason that is still true. So they do the obvious thing. Six weeks later they discover the reason, the expensive way, and the organisation pays a second time for a decision it had already made correctly.

So the artefact that matters most is the smallest one: a record of the decisions, what was rejected, and under what conditions the answer should change.

DECISION

No message broker in the event pipeline

DATE

February 2026

STATUS

Active

CONTEXT

Every service on the platform needs to react to events raised by another. The default answer is a broker, and the platform is operated by one person.

CHOSEN

A durable outbox in the primary database, drained by workers. Delivery survives a crash because it is a database row, not a message in flight. Nothing new has to be kept running for a message to arrive.

REJECTED

A dedicated broker. Correct at a scale this platform does not have, and it would add an operational surface that nobody is on call for.

REVISIT WHEN

Event volume outgrows what polling workers can drain inside the delivery window, or the team is large enough to carry the operational load.

That takes twenty minutes to write and it is worth more to the next owner than a hundred pages describing what the code already says.

The test I actually use

There is one question, and it is behavioural rather than documentary.

Could somebody who has never met me operate this?

Not “is it documented?”, which is a checkbox and can be satisfied dishonestly. Could a person who cannot ask me anything run it, change it, and understand why they are being told not to do the obvious thing?

I have had that question answered for me a few times, which is different from believing it about my own work.

On a government health programme in Africa, the systems I built reached more than fifty clinics between 2016 and 2018, and at the end of the engagement they were handed to a company that would maintain them. Not a knowledge-transfer call. A working estate, delivered to a firm that had never met me, and that then ran it. I was not there for the result. That is what made it a test.

At Elyops, a surgical planning company in Geneva where I had been the entire technical function for two years, I ended the engagement by running the search for my replacement, choosing him, and handing him the platform. He became the CTO. I stayed on as the platform’s technical reference, which I could do lightly and from a distance, because it had been written down for exactly that possibility. Handing it over and staying useful afterwards were the same property of the system, not two different ones.

More recently I specified a rebuild for Solarex, a solar installer in Mauritius that had its own implementer. I made the architectural decisions, the data model, the interface decisions, and wrote them down in enough detail to be built from while I never touched the application code. That is a harder test than it sounds. Being right in a room is easy. Being right in a document that a different person implements from, months later, without you looking over their shoulder, is the actual skill.

The obvious objection

If you build so that you can be replaced, are you not arranging your own redundancy?

I should be careful here, because I am early enough in this practice that I cannot honestly claim a decade of data on it. What I can report is that everything I know points the other way.

The client I handed over most completely, the one whose application code I never wrote a line of, is the one who came back and commissioned the next phase, stock and inventory. The company where I hired my own replacement kept me as its technical reference afterwards. In neither case was I retained because leaving would have been painful. I was retained because staying was useful, which is a much better reason and a far more durable one.

There is also a plainer commercial argument. My work is bought on judgment. A buyer of judgment is choosing between people, and the strongest thing you can put in front of them is not a list of systems you built. It is evidence that the ones you have handed over are running without you.

The other half, which matters as much

None of this means the right engagement is a short one.

I want to be exact about the distinction, because “I make myself unnecessary” can be heard as “I leave”, and that is not what I am describing. Building for handover is not about the duration of the relationship. It is about what the relationship is made of.

If a company keeps me for two years, I want that to be a decision they took, reconsidered, and took again. Not a situation they are in. Those two arrangements look identical from the outside and they are entirely different to be inside of, and only one of them survives the day the client’s interests and mine stop pointing the same way.

That is also the honest description of what an owner’s engineer is for. You are paying somebody to sit on your side of the table, across from vendors and agencies and sometimes from your own team’s preferences. The value of that person collapses the moment they have their own stake in your dependency. It is not a role you can do well while quietly becoming irreplaceable.

What the work is measured by

The temptation I opened with does not go away. The pager still goes off, and it is still satisfying to be the person who knows why.

But the measure of a system is not how well it runs while its author is still there. Almost anything runs while its author is still there. The measure is what happens on the first day somebody else has to change it, and whether that person can find out why they are being told not to do the obvious thing.

Build for that day and you have built something you can give away. Which, it turns out, is the only kind of thing worth being paid to build.