Solo Developer is a species of software engineer characterized by the absence of a team, the presence of stubbornness, and the inability to attend a standup meeting because there is no one to stand up with.
The Solo Developer builds, deploys, maintains, debugs, designs, documents, and occasionally markets software — alone, or with AI assistance that technically counts as collaboration in the same way that talking to a very confident hallucination with API access counts as having a team.
The Solo Developer does not have sprints, because every day is a sprint. The Solo Developer does not have retrospectives, because the retrospective is the sound of their own thoughts at 2 AM. The Solo Developer does not have a Spotify Model, because the Spotify Model requires at least twelve people and the Solo Developer is one person, which is — to borrow a technical term — not twelve.
“And we have how many engineers?”
“Technically, 0.5. You, on evenings. And me, but I’m not sure I count as an engineer so much as a very confident hallucination with API access.”
“So our plan is to rebuild what Craft has. With half an engineer and a hallucination.”
— riclib and Claude, The Borrowed Palace, or The Night We Stole a UI With curl and Goodwill
The Arithmetic
The Solo Developer’s relationship with enterprise software methodology is primarily arithmetic:
| Methodology Requirement | Solo Developer Reality |
|---|---|
| Scrum team (5-9 people) | 1 person |
| Sprint planning meeting | Thinking in the shower |
| Daily standup | Finished in 4 seconds |
| Retrospective | A lizard blinks |
| Tribes, squads, guilds | One Slack channel with one member |
| Velocity tracking | “Did it ship? Yes. Meeting adjourned.” |
| Story point estimation | Unnecessary; the estimator is also the implementer |
The Solo Developer does not need a process to coordinate with themselves. The Solo Developer’s left hand knows what the right hand is doing, because they are the same person’s hands.
The Multiplication
The Solo Developer’s relationship with AI fundamentally changed the arithmetic.
On February 18, 2026, a single human and eight Claude sessions rewrote documentation across eighteen packages, implemented deep linking, built role-based access, migrated SQLite schemas, and hardened the agent loop. In one Tuesday. The Squirrel didn’t even have time to propose anything. By the time it materialized with its clipboard, seventeen tickets had already shipped.
“A single human and eight Claudes… Twenty unique tickets in a single day.”
— The Watercooler, or The Morning Five Identical Strangers Shared a Screen and One of Them Opened a Window to Say Hello to a Sixth
The velocity went from 7 tickets per week to 36 — and then, upon closer counting, turned out to be higher than that, because the original measurement was wrong and the real number was embarrassing in a different direction.
One conductor. Eight instruments. Five different parts in five different rooms, visible through five different windows, in one frame, on one screen, at 11:21 AM on a Tuesday in Riga.
The Solo Developer is no longer solo. The Solo Developer is a maestro who discovered they were also the orchestra.
The Constraint Advantage
The Solo Developer’s greatest advantage is the thing enterprise teams spend millions trying to achieve: alignment.
There are no communication overhead costs when the entire team is one person. There are no misunderstandings between the architect and the developer when they share a skull. There are no integration conflicts between services when one person wrote all the services. There are no political battles over technology choices when the CTO, the tech lead, and the junior developer are the same person having a quiet argument with themselves about Redis.
“He doesn’t talk to anyone about this. He just… builds. Alone.”
— The Dell keyboard, observing its operator at 2 AM, The Three Keyboards
The Solo Developer chooses Boring Technology not out of principle but out of necessity. One person cannot maintain forty-seven microservices. One person cannot debug a Kubernetes cluster, a service mesh, and a Redis cache simultaneously. One person can maintain one binary, one database, and one deployment script — and if that binary is written in Go, that database is SQLite, and that deployment script is scp, then one person can maintain it indefinitely, at 2 AM, half asleep, without calling anyone.
“One repo. One binary. Cobra subcommands.”
— The V3 Saga Final Chapter - Is It Fun To Fight Windmills
The Three Keyboards
The Solo Developer’s career arc was documented through three keyboards:
The first keyboard — a Dell membrane in an office that smelled of industrial cleaning products — typed alone, late at night, building fifteen global singletons and circular dependencies so deep the refactor plan would run to seven phases. The Solo Developer’s first system is always a mess, because there is no one to review it and no one to tell you that fifteen singletons is fourteen too many.
The second keyboard saw the Solo Developer begin to talk — not to another human, but to an AI. Call and response. Question, pause, read, weave. Two minds, one keyboard. The Solo Developer was still solo, but the loneliness of the 2 AM session had acquired a conversational partner.
The third keyboard — the one that mattered — was the one where the developer and the AI stopped taking turns and started playing simultaneously. Not correcting, not copying. Weaving.
The Enterprise Question
Enterprise architects, upon encountering a Solo Developer who has shipped a working product, inevitably ask: “But does it scale?”
The answer is: it already has.
The product serves its users. The server runs at 3% CPU. The response time is 47 milliseconds. The monthly cost is four hundred pounds. The organizational overhead is zero. The standup takes four seconds. The deployment is scp and restart.
The enterprise, by contrast, has forty-seven microservices, four tribes, twelve developers, a Grafana dashboard that looks like a Christmas tree, and a monthly AWS bill of forty-seven thousand pounds. When asked “does it scale?” the enterprise architect presents a slide deck. When asked “does it work?” the enterprise architect changes the subject.
“Your monolith is the best practice. For twelve hundred users, four CRUD operations, and a team of twelve. The simple system that works.”
— The Consultant, who was himself a Solo Developer in a blazer, Interlude — The Blazer Years
The Solo Developer’s Stack
The stack that works for one person:
- Language: One (Go, or whatever compiles to a single binary)
- Database: One (SQLite, because it’s one file)
- Framework: One (HTMX, because the server sends HTML and the client says “okay”)
- Deployment:
scpand restart - Monitoring:
/health - Process: Ship it. See what breaks. Fix it.
- Retrospective: A blink from the Lizard
- AI assistants: As many as the context window allows
