# Solo founder

> A plan for one person building a product alone: set up the Coder, write light house rules, and ship small fixes fast while you keep the big decisions.

You are one person with a product, a backlog, and not enough hours. This playbook puts the Coder to work on the code while you stay in charge of what ships.

## Who this is for

| | |
| --- | --- |
| Company | One founder, one product |
| Team size | 1 |
| Main goal | Get more shipped without hiring yet |
| Start with | The Coder on your main repository |
| Biggest risk | Trusting it too fast, or never trusting it at all |

## Your assistants

| Assistant | Status | Role in this plan |
| --- | --- | --- |
| [Coder](/docs/personas/coder) | Available | Builds features, fixes bugs, keeps checks green, writes tests |
| [Product owner](/docs/personas/product-owner) | Coming soon | Keeps your backlog clear and ranks the week |
| [Marketing](/docs/personas/marketing) | Coming soon | Launch posts and changelogs |
| [Accountant](/docs/personas/accountant) | Coming soon | Invoices and monthly expense summaries |
| [Legal](/docs/personas/legal) | Coming soon | Privacy notice and terms checklists |

> [!SOON]
> Steps marked Coming soon use a persona that is not open yet. Skip them for now and come back when it opens.

## Suggested house rules

As a solo founder you are also the reviewer, so you can let the Coder go further than a larger team would. Paste something like this into your company brief and edit it to fit.

```text
House rules
1. The Coder works on its own branch, never directly on [main branch].
2. For small fixes (a typo, a copy change, a dependency bump, a bug fix under [number] lines), the Coder may merge once all checks pass, and tells me afterwards.
3. For anything bigger, or anything that touches [payments, sign-in, or customer data], the Coder opens a pull request for me to review and waits.
4. Production deploys always wait for my Approve.
5. The Coder adds a test for every bug it fixes.
```

> [!IMPORTANT]
> In [merge policy](/docs/ceo/house-rules#merge-policy) terms, rule 2 is auto merge on green for small fixes and rule 3 is review only for everything else. Your Auto-approve choices in [Settings](https://stellarfirm.ai/app/settings) apply on top of your brief, and nothing is auto-approved until you turn it on yourself. A step that your settings still require you to approve will wait for you. See [approvals](/docs/ceo/approvals).

## Preflight

Finish these before Day 1.

- [ ] Sign in at https://stellarfirm.ai/app with the invitation you received. Self-service sign-up is not open yet.
- [ ] Connect your source host (GitHub, GitLab, or Bitbucket) on [Integrations](https://stellarfirm.ai/app/integrations).
- [ ] Pick one repository to start with.
- [ ] Check that the repository has checks (tests or lint). If it has none, your first goal will be to add them.
- [ ] Write your house rules in the company brief.

## Launch: Day 1

1. **Say hello to the Coder.** Ask it to look around so you both start from the same picture.

```prompt title="Get a first look at the repository"
Coder, look at [repository]. Tell me what it does, how to run its tests, and the three things you would fix first.
```

2. **Run the first goal.** Choose a small, real change.

```prompt title="Your first goal"
Coder, pick up the smallest open issue on [repository]. Build it, run the checks, and show me the changes. Follow our house rules for what happens next.
```

3. **Watch it work.** Open [Jobs](https://stellarfirm.ai/app/jobs) to see the commands and the changes, and [Computer](https://stellarfirm.ai/app/computer) to see its workspace.
4. **Approve the risky step.** When the Coder asks to push and open a pull request, read the changes, then Approve in [Approvals](https://stellarfirm.ai/app/approvals).
5. **Read the result.** By default you get a pull request, as a draft. If it was a small fix and your house rules allow merging, it can ship and tell you.

> [!NOTE]
> **Checkpoint.** By the end of Day 1 you should have one pull request or one merged small fix, and you should know where to read the diff. If the Coder asked you a question, that is a good sign, not a problem.

## First week

| Day | Do this |
| --- | --- |
| 2 | Give the Coder a bug from your list, with a regression test. |
| 3 | Ask it to fix any failing check and to review one of your own pull requests. |
| 4 | Ask for tests on the part of the code you are most afraid to touch. |
| 5 | Review how it went. Loosen or tighten your house rules. |

```prompt title="Fix a real bug"
Coder, on [repository], fix this bug: [description and steps to reproduce]. Find the cause first, add a test that fails without the fix, and then fix it. Follow our house rules for what happens next.
```

```prompt title="Get your own pull request reviewed"
Coder, review pull request #[number] on [repository] as if you were a careful teammate. Point out risks, missing tests, and anything confusing.
```

```prompt title="Get a safety net of tests"
Coder, write tests for [module] on [repository]. Cover the edge cases and do not change the behavior. Open a pull request for review.
```

```prompt title="Check a page in the browser"
Coder, open [page] from [repository] in the browser, click through the main flow, and report anything broken with screenshots.
```

> [!NOTE]
> **Checkpoint.** By Friday you should have merged a few changes, read at least three diffs, and decided which kinds of change you are happy for the Coder to merge on its own.

## Steady orbit

A rhythm that fits around your other work:

- **Monday.** Choose the week's goal. Ask the Coder to take the top ticket.
- **Midweek.** Read the pull requests waiting for you in [Approvals](https://stellarfirm.ai/app/approvals).
- **Friday.** Ask the Coder what shipped and what is stuck.
- **Monthly.** Revisit your house rules. If small fixes keep landing cleanly, widen what the Coder may merge.

```prompt title="Weekly check-in"
Coder, summarize what you shipped on [repository] this week, what is waiting for me, and what is blocked. Suggest the top three things for next week.
```

```prompt title="Clean up after a release"
Coder, look at [repository] after our last release. List any follow-up fixes, flaky tests, or leftover tasks, and open issues for the ones that matter.
```

> [!SOON]
> Routines, which run a prompt like the weekly check-in on a schedule, are Coming soon. Until then, paste the prompt yourself.

## Coming soon for your company

When the other personas open, a solo founder gets the most from these:

- **Product owner:** ranks the week so you always start on the right ticket.
- **Marketing:** turns each release into a changelog and a launch post.
- **Accountant:** summarizes the month's expenses and drafts invoices.
- **Legal:** drafts a privacy notice checklist for your sign-up form, for your lawyer to review.

## Pitfalls

- **Opening the door too wide, too soon.** Start with pull requests for review. Allow merging for small, low-risk changes only after you have read a handful of diffs.
- **Goals that are too big.** "Rebuild the app" produces a diff you cannot review. Ask for one change at a time.
- **Skipping the checks.** Auto-merging only makes sense when your repository has tests. Add them first.
- **Forgetting to name the repository.** Always say which one, especially if you have several.
- **Never reading the diff.** Open the job in Jobs before you approve anything risky.

---

Source: https://stellarfirm.ai/docs/playbooks/solo-founder