Start here
When you build alone, nobody stops you from opening a fifth branch, landing without review, or calling something done because it compiled.
I run my own company this way. I'm the only person in the repository. AI coding agents write most of the code, and a separate agent reviews each change before it lands. Every change still goes through every stage of the Shaped Kanban Playbook: triage, a ready queue, a build limit, review, and acceptance. Only two things change: one person holds every role, and changes land without a pull request.
Read the Shaped Kanban Playbook first. This one covers only what differs when you work alone. Anything it doesn't mention works exactly as the Shaped Kanban Playbook says: the board, the issue form, the limits on open work, sizing and splitting, and flow metrics.
Who this is for
Use it when one person owns the product, the code, and the release, and nobody else reviews or merges. That covers a technical founder before the first engineering hire, or a consultant who maintains a system alone.
Switch to the Shaped Kanban Playbook the day a second person writes or reviews code. The solo rules assume nobody else can be surprised by a change. Once someone can, the second-person controls come back.
1. Hold every role, one decision at a time
Shaped Kanban separates roles to force distinct decisions. One person can hold all of them. Alone, you make each decision at its own moment, with its own evidence.
| Stage | What it means when you work alone |
|---|---|
Triage | You classify the request, write its boundary, and check its size yourself. Never build from a raw idea. |
Ready to build | The issue waits in priority order until Build has room. |
Being built | Move the card, plan before you write code, then build on its own branch. Read the plan as if someone else wrote it. |
In review | An agent that didn't write the change reviews it. Its review replaces the second person. |
In acceptance review | You test the outcome against the issue's scenarios on the real product. |
Shipped / Canceled | Unchanged. Canceling is your decision; nothing cancels work automatically. |
Keep the starter-team limits: two issues in Being built, one in In review. Alone, the limits protect you from yourself. Five open branches mean five half-finished issues.
If an issue turns out too big to finish in one session plus one review, split it and triage the rest. Nobody else will tell you it drifted. A growing distance between your median and 85th-percentile cycle time is the late sign. Operational interrupts still come first; they show up as lower throughput, never as a reason to raise the limits.
If you track work outside your code host, in a task list for example, keep the same stages there and move each card yourself. The land step below changes only code; your tracker stays yours to update.
Done looks like: every change passes through each stage, and the board never shows more than two issues in Being built or one in In review.
2. Land without a pull request
When you're the only reviewer, a pull request adds a round trip and no new reviewer. So each change goes from its own branch to the main branch as one squashed commit, after three gates:
- Automated checks. The tests, type checks, and lint that would gate a pull request run on the exact code you're about to land. Keep them in a pre-push hook in the repository, so every push runs them. A local hook can be bypassed, so run the same checks on the server too, and let nothing deploy until they pass there.
- Independent agent review. An agent with a fresh context, one that didn't write the change, reviews it against the issue. Only serious findings with a concrete failure scenario block the land. Fix them and review again. After two rounds, if a serious finding remains, the change waits for your decision.
- Your explicit go-ahead. Nothing lands because an agent finished. You read the diff and the review, then ask for the land in your own words.
The land step updates the branch onto the latest main, reruns the checks, confirms the review covered exactly this code, squashes, pushes, and only then deploys. If main moved in the meantime, it starts over. It never forces a push.
Never work on the main branch itself. Every change starts on its own named branch, so an unfinished change can't reach production by accident.
Done looks like: a failing check blocks the push, and nothing lands without a fresh agent review and your go-ahead.
3. Accept your own work
Landed code proves the code went in. Acceptance still asks whether the problem is solved, and alone, you're the one asking.
After the deploy, open the issue's Problem, Constraints, and No-gos, and test each scenario on the real product in production. Use the same three results as the Shaped Kanban Playbook. Passed, with evidence, moves to Shipped. Failed, with the unmet criterion named, goes back to Ready to build. Unverified stays in In acceptance review until you can check it. Never mark your own work shipped because it landed.
Write the evidence on the issue: what you tested, where, and what you saw. Next month you won't remember, and that record is the only second opinion you'll have.
Done looks like: every shipped issue carries your written evidence, with what you tested, where, and what you saw.
4. Deploy after the push, and stop the line
Deploy only after the push to main succeeds. A deploy that runs before the push completes can put code in production that never reached a branch, for example when main moved in between.
That order has a cost: the push can succeed while the deploy fails. So treat a broken main or a failed deploy as an incident:
- Land nothing else on top of it.
- Revert the change or fix forward right away.
- Confirm the fix deploys cleanly before you go back to planned work.
Your go-ahead to land covers that one automatic deploy and nothing else. A manual deploy, a retry, a rollback, a database migration, or a change to your cloud setup each needs its own explicit decision.
Done looks like: deploys run only after a successful push, and a failed deploy stops all landing until production is fixed.
5. Agent permissions when you're the only person
The Agent Permissions Playbook assumes a team: a second person approves each change, agents use their own accounts, and no agent deploys. Alone, some of those controls have nobody to hold them. These are the exceptions I accept, and what replaces each one:
| Team rule | Solo exception | What replaces it |
|---|---|---|
| Someone other than the author approves every change. | No second human reviewer. | The automated checks, an independent agent review with a fresh context, and your explicit go-ahead on each land. |
| Agents can't deploy to production. | The land step deploys the change you approved. | It deploys only that change, only after the push, and only when files that ship to production changed. Every other production action waits for your approval. |
| Agents get their own accounts. | Agents work in your signed-in session on your machine. | A separate workspace per task, a short list of allowed tools, and an approval prompt before anything that sends, publishes, deletes, or touches production. |
| Secrets live in a secrets manager. | Local development keys sit in a .env file the repository ignores. | Never commit it. Check in an .env.example with placeholders only, and keep production secrets with your hosting provider. |
Every other rule in the Agent Permissions Playbook still applies: the smallest access that does the job, isolated workspaces, limited network access, activity logs, and no destructive database command until you've named the environment and the data you'd lose.
Done looks like: each exception you use is written down next to what replaces it, and every other rule in the Agent Permissions Playbook still holds.
Start with one change
Add the checks to a pre-push hook, set up a review agent that runs with a fresh context, and take one real issue from triage to an accepted outcome. Whatever step you were tempted to drop is your next improvement.
If you're about to hire your first developer and want this to scale to a team, that's what I set up as a part-time Fractional CTO.