I run production systems alone. Not led a team that built, not architected and handed off. I am the person who gets the alert, and there is no second engineer who knows how any of it works.
People assume the hard part is the volume of work. It is not. The hard part is that every decision has to survive you being unavailable.
Build the monitoring before you need it
On one pipeline I built the observability app before anybody asked for it: per-run cost, per-vendor call counts, error classification, field-mapping gaps, stage-level status. At the time it felt like a detour from the actual work.
It was not. A solo operator cannot hold system state in their head across four clients. Anything I have to remember is a thing that breaks during the week my attention is elsewhere. The app is not really for the client. It exists so I can answer a question in thirty seconds instead of an hour.
Prefer boring recovery over clever prevention
With a team you can afford elaborate correctness, because someone else will review the reasoning. Alone, I would rather be able to replay than be certain I got it right the first time.
So raw payloads are archived before anything parses them, and every stage records what it decided. When a vendor changes a field shape, I reprocess the affected window rather than reconstructing what happened from logs and memory.
Decide what the system will refuse to do
This is the part I underestimated for years. A system run by one person needs a smaller surface than a system run by a team, and the way you get there is by refusing things.
Concretely: no bespoke list pulls that exist only in a Slack thread. No manual step that lives in my habits rather than in code. No feature that needs me awake in a particular timezone. Every one of those is a promise that fails the first time I am somewhere else.
Refusing work is uncomfortable when the client is paying and the request is small. The small requests are exactly the ones that accumulate into a system nobody can maintain.
Write for the person who replaces you
I document as though I am leaving, because eventually I am. Node counts, data flow, the reason a gate exists, the abbreviation forms a classifier has to handle and why they are not obvious from the data.
This is also the honest answer to the risk a client takes by hiring one person. You cannot eliminate that risk. You can make the system legible enough that the next engineer inherits a design instead of excavating one.
What it is actually good for
The upside is real and it has nothing to do with heroics. There is no translation loss. The person who designed an ownership classifier was the person who noticed the abbreviation gap in county data, and the person who fixed it, and the person who backfilled the records it had wrongly skipped. That loop took days. Across a team with handoffs it takes a quarter.
The trade is legibility for speed. It is a good trade on systems under a certain size and a bad one past it. Knowing which side of that line you are on is most of the job.