How to ship alone without the wheels coming off

What a team quietly provides

Before replacing them, name them. A team gives you a reviewer who catches the mistake, a second opinion on design, shared memory of why something is the way it is, and somebody else on call.

Alone you get none of those, and the mistake is assuming the answer is to be more careful. Carefulness does not scale to the four hundredth change and it collapses entirely in the week you are ill.

Each one has to be replaced by something structural.

1. Replace review with structure

A reviewer catches instances. Structure removes classes.

Every time I find a mistake, the question is not “how do I avoid this next time”, it is “how does this become impossible”. The answers are usually cheap:

• A build gate that reads the emitted output and fails on the specific error. This site fails its build if any page has two canonical tags, because that exact bug cost a previous version a year of rankings.
• A schema that validates content, so metadata cannot be too long or contain a character I have banned.
• A type that makes the wrong call fail to compile rather than fail at runtime.
• A database constraint rather than an application check, because the constraint applies to the query somebody writes at midnight too.

The test for whether it worked: could I make this mistake again if I tried? If the answer is yes, the fix was a promise, not a structure.

2. Replace shared memory with writing

Two documents, and they do different jobs.

A plan, while the work is in flight. What is being built, in what order, what is done. Edited as reality lands rather than left as a record of what I hoped. The value is that I can stop for two weeks and resume without reconstructing the state, which happens constantly.

A handoff, when it ships. Not documentation of the code, which the code already provides. A record of the decisions, what surprised me, what I tried that did not work, and the traps.

I wrote these for a hypothetical successor. They turned out to be mostly for me, six months later, with no memory of any of it. The failed approaches section is the most valuable part, because without it I re-attempt things I already disproved.

3. Build the explanation before the feature

The inversion that matters most, and I learned it the wrong way round.

I treated logging, job records and audit trails as things to add once the feature worked. Then the first serious incident was diagnosed by reading the database directly, at length, at night.

When you are alone, the system’s ability to explain itself is a feature with a higher priority than most product features, because it converts a two hour investigation into a two minute one and you personally pay the difference.

Concretely, before the thing that does the work: a record of every job with its outcome, an audit trail for anything that changes money or permissions, and error messages that identify the specific thing that failed rather than the layer that noticed.

4. Design for the incidents you do not want

Being on call alone changes design decisions in a direction that turns out to be correct anyway.

Anything that can fail at three in the morning should either recover by itself or wait until morning without getting worse. In practice:

• Retries with backoff, so a transient failure resolves without a person.
• A sweep that reprocesses anything stuck, so a dead worker is a delay rather than a loss.
• Dead letter queues, so a poison item stops rather than blocking everything behind it.
• Circuit breakers on third parties, so their outage degrades one feature instead of cascading.

The test: for each failure mode, what happens if nobody responds for eight hours. If the answer is that it gets worse, that is the thing to fix before anything else.

5. Deploy small, deploy in daylight

The instinct alone is to batch changes and deploy rarely, because a deploy is a risk with nobody to help. That instinct is exactly backwards.

Infrequent deploys mean large deploys, and a large deploy that goes wrong is unbisectable at the moment you least want a puzzle.

Small changes, deployed during the working day, when you are awake and able to look at it. A deploy that must wait for the small hours is a deploy that happens rarely, and rare deploys are how you get the large risky one.

6. Choose boring, and write down why when you do not

Every clever solution is a liability once you are not the only reader, and the argument that you are the only reader is a bet on your own permanence that is always eventually lost.

Boring, widely understood approaches. Where something genuinely unusual is required, write down why, in the handoff, at the time. The reasoning is worth more than the code, because the code can be reconstructed and the reasoning cannot.

The honest downsides

Two, and pretending otherwise would be dishonest.

No second opinion on design. Some decisions were wrong and stayed wrong for a year because nobody challenged them. The only partial mitigation I have found is writing the argument down as though for somebody else, which catches perhaps half of what a colleague would.

Bus factor. The plans, handoffs and decision records exist for exactly this reason, and they reduce it rather than remove it. It is a real risk and it should be stated as one rather than dressed up as ownership.

What transfers to a team

All of it, which is the part that surprised me. Structure over review makes a team faster because nobody is reviewing for a class of bug that cannot occur. Written plans and handoffs mean work is picked up without a meeting. Systems that explain themselves reduce everybody’s investigation time.

The habits were built out of necessity and turn out to be simply good practice, with the constraint removed.