One developer, production scale

Since 2020 I have built and run a multi-tenant industrial platform as its only developer. It does label printing and product traceability for food and manufacturing customers, it runs in plants, and when a plant loses its internet connection it keeps working and syncs back afterwards.

That is more surface than one person covers well. A web application, an API, a cloud environment, an on-site runtime on hardware in buildings I do not visit, a release path that has to be safe without anyone watching it. Any one of those is a job. Doing all of them has historically meant doing most of them badly. The honest version of a solo platform is a solid product with everything around it half-finished: the second environment, the runbook, the upgrade path, the test for the branch that runs twice a year.

Working with coding agents under a framework changed which parts get neglected. It did not remove the problem. This is what actually changed, and what did not.

The three things it bought

The supporting work stopped getting dropped. The work that goes first when one person is doing everything is never the feature. It is the second environment, the runbook, the test for the path that rarely runs, the upgrade that works when nobody is in the building. That work is well specified, tedious, and exactly what an agent is good at once the standard is written down. On this platform the infrastructure is in Terraform, the pipeline builds once and promotes, security scanning runs before merge, and releases are versioned automatically. None of that is clever. All of it is the kind of thing a sole developer promises to do next month.

Unattended operation became affordable. Each plant host is provisioned with Ansible and runs its services as containers under systemd that pull and apply their own updates. The cutover is gated rather than blind: the new container starts against the same database volume and has to prove the database comes up before anything switches to it. That is a small piece of engineering and I would not have built it alone, because the failure it prevents is rare and the effort is real. With the effort down, the calculation changed. There is nobody on a factory floor at two in the morning to catch a bad release, so the release has to catch itself.

Rework dropped, because the standard is enforced rather than remembered. Every change clears automated gates. A separate reviewing agent attacks the work before it ships. When the same class of problem appears twice the rule is to stop and write the missing specification rather than patch the second instance. Working alone, all of that used to live in my head, which means it applied on the days I had the attention for it.

The three things it did not buy

It did not buy domain knowledge. Knowing that a produce packer labels at lot level and later needs item level, or that a plant's network is the thing most likely to be down, is not in any model. Every good decision on this platform came from the problem rather than the tooling, and an agent given the wrong problem will implement it faithfully and fast.

It did not remove review. It moved it. I spend less time writing and more time deciding whether what was written is right, and that is a real trade rather than a free win. Review is now the bottleneck, and a bottleneck you have chosen is still a bottleneck. Anyone telling you their output went up several times over is either not reviewing carefully or not counting the review.

It did not make the system simpler. There is a framework, a set of gates, a configuration for which model does which job. That is real machinery with its own upkeep, and on a small enough project it would not be worth it. The line is roughly where the cost of the thing you keep failing to do exceeds the cost of the machinery that makes you do it. On a platform running in other people's buildings, that line was crossed a long time ago.

The part that surprised me

I expected the gain to be speed. It was mostly coverage.

The features were never the problem. I can write features. What one person cannot sustain is everything around them: the second environment, the disaster recovery path, the dependency upgrade, the test for the branch that runs twice a year. Those are the things that quietly decide whether a platform is still standing in year four, and they are the first things to go when the person doing them is also doing everything else.

That work is now maintained, not because I became more disciplined, but because the cost of maintaining it fell far enough that discipline stopped being the deciding factor. That is the real answer to what this buys a sole developer, and it is less exciting and more durable than the one people usually give.

If you are considering it

Write the standard down first. An agent enforces a standard that exists and invents one that does not, and the invented one will be different every week.

Gate what you care about, and make the gate fail at least once before you trust it. A check that has only ever passed has not been shown to work.

Expect to spend your time differently rather than to spend less of it. If the promise you are sold is hours saved, ask what happened to the review, because the review is where the hours went.

And be honest about scale. This is one platform, one developer, and a few years. It is enough to say what changed here. It is not enough to tell you what will happen on a team of thirty, and anyone who tells you that from a sample of one is selling something.