# Startup

> A plan for a small product team that ships often: let the Coder merge and ship to staging when checks pass, and keep production deploys behind Approve.

A startup wins by shipping quickly without breaking the product. This playbook lets the Coder move fast on staging, while production stays behind your Approve.

## Who this is for

| | |
| --- | --- |
| Company | A product team with customers and a deployment pipeline |
| Team size | 3 to 30 |
| Main goal | Shorten the path from ticket to shipped change |
| Start with | One Coder on the main product, then a second for another area |
| Biggest risk | A change reaching production without enough review |

## Your assistants

| Assistant | Status | Role in this plan |
| --- | --- | --- |
| [Coder](/docs/personas/coder) | Available | Builds tickets, fixes CI, writes tests, reviews pull requests |
| [Product owner](/docs/personas/product-owner) | Coming soon | Triages the backlog and writes tickets the Coder can build |
| [Marketing](/docs/personas/marketing) | Coming soon | Changelogs and launch posts |
| [Accountant](/docs/personas/accountant) | Coming soon | Expense summaries and invoices |
| [Legal](/docs/personas/legal) | Coming soon | Terms and privacy checklists |

> [!SOON]
> Today the Coder carries the delivery loop. The Product owner will take over ticket writing when it opens.

## Suggested house rules

```text
House rules
1. The Coder works on its own branch and opens a pull request for every change.
2. If all checks pass and the change touches only [areas, such as docs, copy, or tests], the Coder may merge to [staging branch] and tells me afterwards.
3. Changes to [payments, sign-in, database changes, or infrastructure] are opened as pull requests for a teammate to review. A person merges them after review.
4. A deploy to production always waits for my Approve, with a summary of what is in it.
5. If a check fails twice, the Coder stops and asks instead of trying a third time.
6. Every bug fix includes a regression test.
```

> [!IMPORTANT]
> This is a starting point. In [merge policy](/docs/ceo/house-rules#merge-policy) terms, low-risk areas use auto merge on green to staging, sensitive areas stay review only, and production ships only after CEO approval. The Coder can merge and ship when your house rules allow it, and your Auto-approve choices in [Settings](https://stellarfirm.ai/app/settings) apply on top. Production actions ask unless you have turned off that ask yourself, so keep it on.

## Preflight

- [ ] Sign in at https://stellarfirm.ai/app with your invitation.
- [ ] Connect your source host on [Integrations](https://stellarfirm.ai/app/integrations).
- [ ] Make sure your repository has checks that run on every pull request. If not, make "set up CI" your first goal.
- [ ] Name the staging branch, and say who reviews what.
- [ ] Write your house rules in the company brief.

## Launch: Day 1

1. **Check the safety net.** Ask the Coder how healthy your checks are.

```prompt title="Check the health of CI"
Coder, look at the checks on [repository]. Tell me what runs on each pull request, how long it takes, what is missing, and what is flaky.
```

2. **Run a first ticket.**

```prompt title="First ticket"
Coder, pick up the top open ticket on [repository]. Build it, run the checks, and open a pull request. Follow our house rules for what happens next.
```

3. **Watch it in Jobs.** Read the commands and the diff in [Jobs](https://stellarfirm.ai/app/jobs).
4. **Approve the risky step** in [Approvals](https://stellarfirm.ai/app/approvals).
5. **Have a teammate review** the first pull request like any other.

> [!NOTE]
> **Checkpoint.** By the end of Day 1 one real ticket has become a pull request, and your team knows where to find the Coder's work.

## First week

| Day | Do this |
| --- | --- |
| 2 | Let the Coder fix a failing check and a flaky test. |
| 3 | Give it a small feature with a clear acceptance list. |
| 4 | Allow it to merge a low-risk change to staging, if your house rules say so, and watch what it does. |
| 5 | Review the week with the team and adjust the house rules. |

```prompt title="Build from acceptance criteria"
Coder, on [repository], build this ticket: [title]. Acceptance criteria: [list]. Add tests that prove each criterion and open a pull request.
```

```prompt title="Fix a failing pipeline"
Coder, the pipeline on [branch or pull request] in [repository] is red. Find the cause, fix it in the smallest change, and explain what went wrong.
```

```prompt title="Hunt a flaky test"
Coder, [test name] on [repository] fails now and then. Find out why, fix the cause, and do not just add a retry.
```

```prompt title="Prepare a production release summary"
Coder, list what is on [staging branch] but not yet in production on [repository]. Group it by risk and tell me what I should check before I approve a deploy.
```

```prompt title="Review a teammate's pull request"
Coder, review pull request #[number] on [repository]. Summarize it, flag risks and missing tests, and say what you would ask the author.
```

```prompt title="Improve CI speed"
Coder, make the checks on [repository] faster without making them weaker. Show me the before and after times in the pull request.
```

> [!NOTE]
> **Checkpoint.** By Friday you have merged a few changes to staging, caught at least one failing check early, and written down which areas are safe for the Coder to merge on its own.

## Steady orbit

- **Every ticket.** Name the Coder, the repository, and where to stop.
- **Every day.** Clear [Approvals](https://stellarfirm.ai/app/approvals), then read the staging summary.
- **Before each production deploy.** Ask for the release summary, then approve with the summary in hand.
- **Every sprint.** Add a second Coder for a second area, for example UI and API, each with its own focus.
- **Every month.** Widen or narrow what the Coder may merge, based on how the last month went.

```prompt title="Sprint retrospective"
Coder, look at the pull requests you opened on [repository] this sprint. Which needed changes, why, and what should we change in our house rules?
```

## Coming soon for your company

- **Product owner:** keeps the backlog in shape so the top ticket is always buildable.
- **Marketing:** turns each release into a changelog entry.
- **Accountant** and **Legal:** keep the books and the policies tidy as you grow.

## Pitfalls

- **Merging without checks.** Letting the Coder merge only makes sense with checks that mean something. Fix CI first.
- **Production by default.** Keep production deploys behind Approve until you have a long track record.
- **One giant Coder.** Add a second Coder with its own focus before one Coder becomes a bottleneck.
- **Unclear tickets.** A ticket with no acceptance criteria gets a guess. Add criteria, or ask the Coder to propose them first.
- **Not reading summaries.** The Approve card is only useful if you read what it says.

---

Source: https://stellarfirm.ai/docs/playbooks/startup