The Solo Stack

I ran an agency of thirty people and never shipped as much in a year as I ship now in a quarter, alone. The naive explanation is that AI writes code fast. That is true, and it misses the point the way 'a car is a fast horse' misses the point. Typing was never the bottleneck of a one-person operation. Everything else was.

By Jordi Buskermolen7 min read
ai-systemsbuilding
The Solo Stack

With thirty people at my previous agency I never shipped as much in a year as I ship now in a quarter, alone. A board app with a waitlist, a coaching platform with a paying cohort on it, a bookmark search tool people use every week, a content calendar with its own publisher, a monthly measurement that runs itself, a lead-screening pipeline, a podcast archive, a client product that took five weeks. All live. All maintained. One person.

Four years ago that sentence would have been a lie. It is not one anymore, and the reason is not the one people reach for.

The naive explanation of AI-assisted development is speed. The machine types faster than you, so you ship more. True, and it misses the point the way "a car is a fast horse" misses the point. Typing was never the bottleneck of a one-person software operation. Everything else was: the architecture decisions with nobody to argue against, the code review that does not happen, the security pass there is no specialist for, the eight projects' worth of context that has to live in one head, and the arithmetic that every shipped app is a permanent maintenance liability signed in your name only.

AI did not remove those problems. It made them the whole job. And it made them survivable, if you run the operation with a discipline most solo developers never needed before, because before, the ceiling arrived long before discipline mattered.

The job changed, and most people have not noticed which job they do now

The productive stance is closer to a technical director with a very fast, very well-read, occasionally overconfident senior contractor than to a developer with a better keyboard. The contractor writes the code, knows every API, produces in minutes what took days. What stays mine is deciding what to build, specifying it precisely enough to build from, reading what comes back, and owning the consequences. The contractor is never on call. I am.

I wrote last week that I merge about twenty-five batches of agent work a day on one product. That number is the job. Not the forty agents, the twenty-five reads. Does it do what was asked, what did it silently assume, and what would a hostile user do to it. Those three questions, twenty-five times, is a working day.

The part that changed my daily practice most is where the leverage sits. It is in the plan before the code, not in the code. An hour spent writing down what we are building, what is explicitly out, which existing patterns to follow and what "done" means saves the afternoon of unwinding a fast, confident, wrong implementation. I learned this the way everyone does: two weeks ago I skipped it on a feature that felt small, the agents built a clean, tested version of the wrong thing, and I spent longer deleting it than the plan would have taken. Solo builders who skip the plan do not ship faster. They ship sideways.

Every application looks the same, on purpose

A team can afford variety. Someone always remembers how the strange service works. One brain running eight apps cannot. So the rule that sounds like stagnation and works like a superpower: every application I build looks the same. Same framework. Same database pattern. Same authentication. Same folder structure, same deployment, same logging, same admin pages. New project, clone the skeleton.

Three things compound from that. Context-switching gets cheap: I can open a project after three months away and everything is where everything always is, which is the tax that kills most multi-project solos. The agents get better: an agent working inside a strongly conventioned codebase, told to follow the existing patterns, produces far more consistent code than one improvising in a new structure. The conventions are, in effect, a standing instruction. And every solved problem is solved portfolio-wide. The backup script, the rate limiting, the social-preview images: fixed once, propagated everywhere, because everywhere is the same place.

The cost is real. Sometimes the boring tool is twenty percent worse than the shiny one for this specific case. I pay it. The twenty percent local optimum is how a solo portfolio becomes eight unmaintainable snowflakes. The boring convention is how it stays one system wearing eight masks.

By the same logic, my repeated prompts became infrastructure. The planning prompt that produces a plan and touches nothing. The security sweep that runs before every launch and after every big change, with findings reported and nothing fixed until I approve. The pre-launch checklist that catches the leftover noindex tag. Each one encodes a judgment once and applies it every time, which is the same move as naming a method, because it is one. Two rules sit under all of them and I hold them as absolutes, because the exceptions are how incidents happen: verify before trusting, and approve before acting on anything that touches production data, money, deletion or a user's trust.

The team I do not have, rebuilt as guardrails

A team gives you for free the things a solo builder has to build on purpose: someone else's eyes, someone else's memory, someone who notices at three in the morning. The replacements are cheap and none of them is optional.

The security audit is a ritual on the calendar, not a reaction to a scare. Tests go where they pay: the money paths, the login paths, the places where one user could see another's data. Not coverage for its own sake. Error alerts reach my phone, every app has one uptime monitor, and the logs can be searched, because a solo operation's one advantage over a team is that I find out immediately, and forfeiting that leaves a team-sized blind spot with no team. Backups exist and have been restored at least once, since an untested backup is a feeling.

I will add the one I learned this month, because it belongs here. On the first of October the measurement I run every month failed partway, six responses missing, because an API account ran out of credit and I had not topped it up. The instrument did its job and recorded the holes as holes. The guardrail that was missing was a trivial one, auto-recharge, and it was missing because I had never written "the accounts the instruments depend on" onto the list of things that get checked. It is on the list now. That is how the list grows: not from theory, from the Thursday morning something was not there.

Scope is the oxygen

Every app you ship is a standing liability. Dependencies age, platforms shift, users email. So the portfolio runs on scope rules that feel almost severe.

Small products that do one job completely beat a platform that does five jobs at version 0.7 forever. Validation comes before scaffolding: the cheap, throwaway slice that answers whether the core works and whether anyone wants it, before an account system or a settings page exists. Budget spent on polish before that answer is the solo builder's most common self-inflicted wound, and I have the folder of fifteen to twenty half-finished projects to prove I know it from the inside. One honest iteration, then ship, and let reality decide what the second iteration is. And kill things. Every quarter, each app gets the same question: does it still earn its maintenance? A project that serves nothing but still takes updates is paying rent to your past self. Several of mine are paused right now for exactly that reason, and the attention came back the week I stopped pretending otherwise.

The arithmetic underneath all of this is simple. The capacity limit of a one-person operation is not building. AI moved that ceiling a long way off. The limit is carrying. Every live product takes permanent space in one head and one calendar, and the conventions and the guardrails exist to push the per-app carrying cost toward its floor, so that the count of things carried can stay honest against what is left.

Which leaves the boundary of the whole model, and I would rather state it than have someone discover it for me. AI multiplied the building. It multiplied nothing else. Support is still me, reading a confused user's email with care. Sales is still me, in conversations that cannot be batched. The client relationship, the referral, the judgment about which product deserves this quarter: one person, slow, unscalable. Everything in this article is a machine for spending that one person's attention only where it counts, and the day I forget that the machine is the point, I will have built the thirty-person agency again, with nobody in the other twenty-nine chairs.

Originally published on LinkedIn.

Want more of this?

I write regularly on LinkedIn about what I'm building and learning: agency growth, AI development, product judgment, and the messy reality behind making things work.

Follow on LinkedIn