# Agency

> A plan for a studio running several client projects: one Coder per client, pull requests for review, and every client-facing step behind Approve.

An agency lives or dies on trust. Clients must never see work you did not check. This playbook gives each client project its own Coder and keeps every client-facing step behind your Approve.

## Who this is for

| | |
| --- | --- |
| Company | A studio building sites and apps for several clients |
| Team size | 3 to 25 |
| Main goal | Deliver more client work without losing control of quality |
| Start with | One Coder per client project |
| Biggest risk | Work reaching a client, or landing in the wrong repository, before you reviewed it |

## Your assistants

| Assistant | Status | Role in this plan |
| --- | --- | --- |
| [Coder](/docs/personas/coder) | Available | One Coder per client: builds, fixes, tests, and opens pull requests |
| [Product owner](/docs/personas/product-owner) | Coming soon | Turns client requests into clear tickets |
| [Marketing](/docs/personas/marketing) | Coming soon | Client announcements and your own case studies |
| [Accountant](/docs/personas/accountant) | Coming soon | Invoices and payment reminders per client |
| [Legal](/docs/personas/legal) | Coming soon | Contract and NDA review checklists |

> [!SOON]
> Reports, posts, and client updates come with the next hires. Today your agency office is the Coder, and the plan below is built around it.

## Why one Coder per client

Each Coder has its own name, focus, repository, login to the source host, and private workspace. That separation is what keeps client work apart.

- Client A's code never sits in the same workspace as client B's.
- Each Coder uses a login that only reaches its own client's repository.
- You can address one by name, so a request about a client goes to the right place.
- Approvals and retries go back to the Coder that ran the job.

Add Coders under Coders in [Settings](https://stellarfirm.ai/app/settings). See [the Coder](/docs/personas/coder#several-coders).

## Suggested house rules

Keep these strict. You can relax them for internal projects later.

```text
House rules
1. Each Coder works only in its own client's repository.
2. The Coder always works on its own branch and opens a pull request for review. A person on our team merges after review.
3. Nothing is published, deployed, or sent to a client until I approve it.
4. Every pull request description says what changed, how it was tested, and what to check.
5. No client names, secrets, or personal data in prompts or pull request descriptions.
6. For internal projects (our own site, our own tools), the Coder may merge small fixes after checks pass.
```

> [!IMPORTANT]
> Rule 2 is a choice for client work, not a limit of the Coder: it sets the [merge policy](/docs/ceo/house-rules#merge-policy) to review only. The Coder can merge when your house rules allow it, which is why rule 6 can allow it for internal projects. Your Auto-approve choices in [Settings](https://stellarfirm.ai/app/settings) apply on top, and nothing is auto-approved until you turn it on.

## Preflight

- [ ] Sign in at https://stellarfirm.ai/app with your invitation.
- [ ] Connect your source host on [Integrations](https://stellarfirm.ai/app/integrations). If clients keep code in their own accounts, connect a login that has access to just those repositories.
- [ ] List your active client projects and their repositories.
- [ ] Decide who on your team reviews each client's pull requests.
- [ ] Write the house rules in your company brief.

## Launch: Day 1

1. **Add a Coder for your most active client.** Name it after the client or the project, and give it a short focus, such as "Acme storefront, React".
2. **Point it at the client's repository.** Add the repository in the Coder's settings.
3. **Run a small first goal.**

```prompt title="First goal for a client Coder"
[Client] Coder, look at [repository] and tell me what the project is, how to run its tests, and what the open issues are. Do not change anything yet.
```

```prompt title="A small real change"
[Client] Coder, pick up the smallest open issue on [repository]. Build it, run the checks, and open a pull request for review with a clear description.
```

4. **Review in Jobs.** Read the diff in [Jobs](https://stellarfirm.ai/app/jobs). Approve the push in [Approvals](https://stellarfirm.ai/app/approvals) when it looks right.
5. **Review the pull request** the way you would any teammate's.

> [!NOTE]
> **Checkpoint.** By the end of Day 1 one client has a Coder that opened one pull request in the right repository, and your reviewer has looked at it.

## First week

| Day | Do this |
| --- | --- |
| 2 | Add Coders for two more clients, each with its own repository. |
| 3 | Ask each Coder to review one open pull request and to fix any failing check. |
| 4 | Ask for a test pass on the riskiest part of one client's code. |
| 5 | Review the week: which pull requests needed changes, and why. Update the house rules. |

```prompt title="Fix a failing check for a client"
[Client] Coder, the checks on pull request #[number] in [repository] are failing. Find the cause and fix it in the smallest change. Open a pull request for review.
```

```prompt title="Build a feature from a client request"
[Client] Coder, the client asked for: [request]. On [repository], build it in a way that matches the existing code style. Check the page in the browser and attach screenshots to the pull request.
```

```prompt title="Review before the client sees it"
[Client] Coder, review pull request #[number] on [repository] as a careful senior developer. List risks, missing tests, and anything the client would notice.
```

```prompt title="Prepare a client-ready summary"
[Client] Coder, write a short, plain-language summary of the changes in pull request #[number] on [repository], suitable for me to paste into an update for the client. Do not send anything.
```

```prompt title="Add tests before a risky change"
[Client] Coder, before we change [area] on [repository], write tests that lock in how it works today. Open a pull request for review.
```

```prompt title="Weekly status across clients"
Team, for each client Coder, summarize what shipped this week, what is waiting for my review, and what is blocked.
```

> [!NOTE]
> **Checkpoint.** By Friday each active client has a Coder, every pull request has a reviewer, and nothing reached a client without your Approve.

## Steady orbit

- **Monday.** Choose each client's top goals and brief the Coders.
- **Daily.** Clear the waiting items in [Approvals](https://stellarfirm.ai/app/approvals).
- **Before each client call.** Ask the client's Coder for a summary of what shipped.
- **Monthly.** Review house rules per client. Some clients may earn more freedom than others.
- **When a client leaves.** Remove its Coder and its login.

> [!SOON]
> Ready-made companies, including an agency office, are Coming soon. They will set up assistants, house rules, and a starter brief for you.

## Pitfalls

- **One Coder for many clients.** Mixing clients in one Coder blurs repositories and logins. Give each client its own.
- **Shared logins.** Use a login that reaches only the repositories that Coder needs.
- **Naming the client in prompts when it should stay private.** Use short project names if your contract requires confidentiality.
- **Letting speed beat review.** Client trust is the product. Keep client-facing steps behind Approve.
- **Vague client requests.** Paste the request as written and ask the Coder to list its questions before it starts.

---

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