an agentic sdlc for a company of one

most evenings, i open my laptop to a handful of draft pull requests that weren’t there in the morning. each one closes a specific issue from my backlog. each has already been through review, a qa pass, a security check, and where it matters, a legal check. my part is now to read them and decide what ships.

i’m the only person on the product. there’s no team behind those pull requests. there’s a team of agents.

i build indebtio, a danish self-service debt-collection product. it’s bootstrapped, it’s live, it has paying customers, and the data it holds is the kind you don’t get to lose. i work on it in the margins, which means the one resource i can’t buy more of is my own time. i’m not going to raise a round and hire five engineers. so the question that shapes everything is: how does one person ship like a team?

the answer i’ve landed on is an agentic sdlc: scaling with agents instead of headcount. not one general agent that “does the work,” but a small org of specialized ones, organized into teams, running most of a software development lifecycle while i stay on the two decisions that actually need a human.

three pieces, none of them exotic

the whole thing runs on tools a solo founder already has:

• linear holds the backlog and the state of every piece of work. an issue moves through backlog, queued for agents, building, in review, done. that column is the source of truth for what the agents are allowed to touch.
• github holds the code, and every change as a pull request. nothing reaches the product except as a pr i can read.
• claude code runs the agents, on a schedule, in the cloud.

here’s the backlog itself in linear, grouped by discipline — each discipline is a team:

the interesting part isn’t the tools. it’s how the work is organized between them.

teams and personas

i don’t have one agent that does everything. i have teams, and each team is a pipeline of small, narrow agents i call personas. each persona does one job and hands off to the next.

engineering is the clearest example. a queued issue passes through a refiner that turns it into precise acceptance criteria, a designer that decides the approach, an implementer that writes the code on a branch, then a sequence of gates: a reviewer, a qa agent that adds tests, a security reviewer that checks data scoping and authorization, and a legal reviewer — a jurist — that checks the danish debt-collection rules the feature has to respect. only the implementer writes code. everyone else reads, judges, and either passes it on or sends it back with specific feedback.

other teams have the same shape but different work: reliability turns errors into surgical fix prs with regression tests, growth builds landing and pricing pages, content writes articles, compliance keeps the legal copy correct, support writes help articles. each is a label in linear with its own pipeline and its own personas.

the personas don’t all run on the same model. the judgment-heavy roles — designer, implementer, and the qa, security, and legal gates — use the stronger model; the narrower, more mechanical ones use a faster one. that mix is deliberate: it keeps the whole thing cheap enough to run every single day, which on a bootstrapped budget is the difference between a habit and a demo.

the swarm page

i run all of it from one page i built for myself — a swarm dashboard that shows every team at a glance.

across the top: what’s waiting for me to review, what’s building right now, what’s queued, how many draft prs are open, how much is sitting in the backlog. there’s a box where i drop a one-line thought; a triage agent reads it, picks the team it belongs to, and files it as a proper issue. and there’s the work itself — the same handful of teams, each with its own board and its own time in the morning.

that’s the cockpit. the flow underneath it is boring on purpose, which is what makes it trustworthy.

ideas go into the backlog. some i write, some a research agent proposes, some start as that one-line thought in the box. then i decide which are worth doing and move them into “queued for agents.” that’s the first gate.

every morning, a scheduled cloud agent wakes up for each team, staggered half an hour apart. it reads its team’s queue, and for each issue it creates a branch, runs the full pipeline, and opens a draft pull request whose body starts with “closes” and the issue number. then it stops. the routines never merge. they’re not allowed to.

so i come back to draft prs, each tied to an issue, each already argued over by the review gates. i read them, i merge the ones that are right, and i send back or close the ones that aren’t. that’s the second gate.

the two gates are the point

if there’s one idea i’d want another founder to take from this: the leverage is in the middle, and the judgment is at the ends.

deciding what’s worth building is judgment. deciding what’s good enough to ship is judgment. i kept both. everything between them — the refining, the designing, the writing, the testing, the checking — is structured enough that a team of agents can do it during the day, and reviewable enough that i can catch it when they get it wrong.

and they do get it wrong. this is the honest part. i throw away work the agents produce. some prs miss the point of the issue, some solve it in a way i don’t want, some trip a gate and never reach me at all, which is the system working. the draft-only rule isn’t a formality. it’s the thing that lets me run agents against a production codebase without losing sleep.

and it only works because of the structure around it. each persona has written rules: what it owns, what it must not touch, how to scope a database query, how to cite a statute. this isn’t a clever prompt. it’s a backlog, a set of narrow roles, a pipeline, a swarm page to watch it, and two human gates, wired into the tools i already use.

what this bought me

before this, the routine work — the small fixes, the missing test coverage, the help article that should exist, the landing page i kept meaning to write — sat in the backlog because there was always something more urgent. as a team of one, “more urgent” wins every time. now a lot of it arrives as a draft pr by the time i sit down in the evening, and i spend my time deciding rather than typing.

that’s the change i’d describe to another bootstrapper. not that the work writes itself, because it doesn’t, and not that i’ve replaced myself, because i haven’t. i moved my own time to the two decisions that need me, and handed the structured middle to a team that works while i’m away from the keyboard. for one person running a real product, that’s a meaningful amount of leverage to find without raising a round or making a hire.