Solo founder coding agents: shipping a product alone
Stefan-Iulian Tesoi · · 6 min read
The hard part is not the code, and it is not deciding what to build. It is holding both at once. A solo founder is the product owner and the reviewer, and once agents are writing the code those two jobs compete for the same hour every day, with nobody to hand either of them to.
Solo founder coding agents change the shape of the week rather than its length. The typing shrinks. What expands is the deciding and the judging, and those are the two activities that are worst at sharing a calendar.
Where do solo founder coding agents actually help?
With the part of the day that was never the interesting part. Boilerplate, migrations, test scaffolding, the fourth CRUD endpoint, the refactor you have been avoiding — work where the requirement is obvious and the effort is real.
They help least with the work where knowing what to build is the work. That distinction matters more when you are alone, because a team has people whose judgement differs from yours and a solo founder has only the agent's agreement, which is not the same thing.
Which agent you run is close to a commodity decision. Claude Code, Cursor and any other MCP-capable client behave much the same here, and what they are connected to matters more than which one you picked — the case for that is in Jira alternatives when an agent reads your backlog.
On a team, the person who writes the ticket and the person who reviews the result are usually different people, and the gap between them catches mistakes. Alone, that gap closes. You review your own specification, executed faithfully.
Two roles, one calendar
Specifying and reviewing are different mental jobs, and alternating between them costs more than doing either. Specification is open-ended and generative; review is convergent and sceptical. Switching between tasks of different kinds carries a measurable cost — the American Psychological Association's summary of the research on switching costs puts it plainly, and anyone who has approved a pull request in the middle of writing a spec has felt it.
The practical consequence is that building a product alone with AI goes badly when the day is interleaved. An agent finishes, a notification arrives, you stop mid-thought to look at a diff, and the item you were half through writing gets finished in a hurry afterwards. The rushed item is the one that comes back wrong, which produces another review, which interrupts the next specification.
Batching is the whole fix, and it is unglamorous: one block for specification, one for review, and the agent runs between them. Two blocks of about ninety minutes covers a realistic day's work for one person running one or two agents. How the ceiling on agent count actually works is in how many coding agents one team can run.
Which half should you keep?
Keep the judgement. Hand over the mechanics. The two halves separate more cleanly than founders expect, and the line is not between thinking and typing.
| Keep | Hand over |
|---|---|
| What is worth building next | Turning that decision into an executable item |
| What "done" actually means | Producing the change |
| Whether returned work is right | Running the checks that prove it ran |
| Talking to users | Chasing status and keeping the board true |
The second row of the right-hand column is the one people miss. Writing a decision down so an agent can act on it is real work — criteria, context, which files, what must not break — and it is not the same skill as making the decision. It is closer to editing than to founding, and it is the first thing worth handing over, because it is the step that gets skipped at 11pm.
This is the honest place to name Laimonade: it grooms the backlog into items an agent can execute, hands them over, and checks what comes back against the criteria. A person still decides what is done — the agent carries an item as far as review and stops. For a one person software company the interesting part is not the automation, it is that the judgement stays where it has to be while the clerical half does not need you awake. What that costs is on the pricing page, what it looks like on day one is in getting started, and the version of this written for founders is Laimonade for solo founders.
What does a week actually look like?
Four working shapes, not five identical days. A solo developer AI workflow that survives contact with a real week tends to settle into something like this.
- Monday: decide. What is the next thing worth building, and why this rather than that. No implementation, no agent. This is the hour that protects the other four days.
- Tuesday to Thursday: specify in the morning, review in the afternoon. Two or three items specified properly is a realistic daily rate alongside everything else a founder does. Agents work through the gap.
- Friday: look outward. Talk to users, read support, check what people actually did in the product. Nothing gets specified on a Friday.
- Any day: stop when the queue is empty rather than filling it. An agent with nothing specified to do is cheaper than an agent given something vague.
Sprints still help when you are alone, and for a reason that sounds odd until you have skipped one: a sprint boundary is the only thing that forces a solo founder to admit what did not get finished. Without it, unfinished work rolls silently forward and the plan is always on track.
How do you avoid building the wrong thing quickly?
Put a customer check between deciding and building, because agents removed the delay that used to provide one.
The old process had accidental protection in it. An idea took two weeks to build, and somewhere in those two weeks you talked to someone, or reread it and lost enthusiasm, or a harder problem intervened. Attrition killed the bad ideas for free. When the gap between "this seems good" and "this is deployed" collapses to a day, nothing is killed by attrition any more, and every idea gets built.
The failure that follows is specific and common: three features shipped in a week, none of which touched the reason people were leaving. The velocity was real. It was spent on the founder's own hypotheses, tested against nobody, and the speed made it feel like progress the entire time.
Two cheap defences work. Write down the outcome an item is supposed to produce, in the item, before it is built — not the feature, the change in behaviour you expect to see. Then look, a week later, at whether that happened. Most items fail the first test before anything is built, which is the point.
Frequently asked questions
How many agents can a solo founder supervise?
Usually one, occasionally two. The limit is not the tooling, it is how many items one person can specify well and review honestly in a day, and both numbers are small when that person also sells, supports and does the accounts. Starting with one agent and a genuinely executable backlog beats three agents and a hopeful one.
Do you still need sprints when you are alone?
Yes, and for a different reason than a team does. A team uses a sprint to coordinate; a solo founder uses it to be held to something. The boundary is what makes unfinished work visible instead of quietly rolling forward, and a fortnight is long enough to build something real and short enough that a bad direction gets caught.
What is the first thing to hand over?
Turning decisions into executable items, not writing the code. Founders reach for code generation first because it is the visible work, then discover the constraint moved to specification. Handing over the drafting of items — criteria, context, what must not break — is what keeps the queue full enough for a coding agent to be worth running.
Does this mean the agent decides what to build?
No, and building that way is how the wrong product gets shipped fast. An agent can draft, implement and check against stated criteria. What is worth doing, what "done" means and whether returned work is genuinely right stay with the person, because those answers depend on customers and a runway that the repository knows nothing about.