# Small business

> A plan for a shop, practice, or service business with a website and a few tools: start with everything behind Approve, then loosen as trust grows.

You run a business, not a software team. Maybe you have a website, an online booking page, or a small app that a freelancer built. This playbook uses the Coder to keep that code healthy, with everything behind your Approve at first.

## Who this is for

| | |
| --- | --- |
| Company | A shop, practice, studio, or service business with a website or small app |
| Team size | 2 to 20 |
| Main goal | Keep your website and tools working and up to date without a full-time developer |
| Start with | The Coder on your website repository |
| Biggest risk | A change going live that you did not understand |

## Your assistants

| Assistant | Status | Role in this plan |
| --- | --- | --- |
| [Coder](/docs/personas/coder) | Available | Fixes issues, updates pages, and keeps the site working |
| [Product owner](/docs/personas/product-owner) | Coming soon | Turns your wish list into clear tickets |
| [Marketing](/docs/personas/marketing) | Coming soon | Announcements, emails, and social posts |
| [Accountant](/docs/personas/accountant) | Coming soon | Invoices, reminders, and monthly summaries |
| [Legal](/docs/personas/legal) | Coming soon | Privacy notice and terms checklists |

> [!SOON]
> The Accountant, Marketing, and Legal assistants are the ones a small business will lean on most. They are Coming soon. Today, start with the Coder and the website.

## Suggested house rules

Keep everything behind Approve at first. Widen it later.

```text
House rules
1. The Coder works on its own branch and opens a pull request for every change.
2. Nothing goes live, is sent, or is deleted until I approve it.
3. Before each change, the Coder explains in plain words what it will do and why.
4. After each change, the Coder tells me what to look at on the website to confirm it works.
5. The Coder never changes [payments, booking, or customer data] without asking me first.
6. If something is unclear, the Coder asks me a question instead of guessing.
```

> [!TIP]
> These rules use the review only [merge policy](/docs/ceo/house-rules#merge-policy), the default. After a few weeks of small, correct changes, you may move to auto merge on green and allow the Coder to merge tiny, low-risk edits such as a text change once the checks pass. 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.
- [ ] Find out where your website's code lives (usually GitHub, GitLab, or Bitbucket). Ask whoever built it if you are not sure.
- [ ] Connect that account on [Integrations](https://stellarfirm.ai/app/integrations).
- [ ] Write a few lines about your business for the company brief: what you do, who you serve, and how you sound.
- [ ] Add the house rules above to the brief.

## Launch: Day 1

1. **Ask the Coder to explain your website in plain words.**

```prompt title="Understand what you have"
Coder, look at [repository] and explain in plain words what the website does, which pages it has, and what looks out of date or risky. I am not a developer, so keep it simple.
```

2. **Run a first, tiny change.**

```prompt title="A first small change"
Coder, on [repository], change [text or detail, such as opening hours on the contact page] to [new value]. Show me what will change on the page and open a pull request for my review.
```

3. **Watch it work.** Open [Jobs](https://stellarfirm.ai/app/jobs) to see the changes.
4. **Approve the risky step.** When the Coder asks to push and open a pull request, read its plain-language summary and Approve in [Approvals](https://stellarfirm.ai/app/approvals).
5. **Check the result** on the website once your changes are live.

> [!NOTE]
> **Checkpoint.** By the end of Day 1 you understand what your website is made of and one small change has gone through the whole path: goal, work, Approve, pull request.

## First week

| Day | Do this |
| --- | --- |
| 2 | Ask for a check-up: broken links, slow pages, and outdated parts. |
| 3 | Fix the top item from the check-up. |
| 4 | Ask the Coder to check the booking or contact form in the browser. |
| 5 | Review the week. Keep the house rules, or loosen one. |

```prompt title="Website check-up"
Coder, check [repository] for broken links, missing page titles, images that are too large, and anything that looks out of date. Give me a short list in order of importance. Change nothing yet.
```

```prompt title="Test the contact form"
Coder, open the contact form on [website or repository] in the browser, fill it in with test details, and tell me whether it works, with screenshots. Do not send anything to real customers.
```

```prompt title="Update a page"
Coder, on [repository], update the [page] with this text: [new text]. Keep the same style, check it looks right on a phone, and open a pull request for review.
```

```prompt title="Fix something that is broken"
Coder, customers tell me that [problem, such as the booking button does nothing]. Find the cause and explain it to me in plain words before you fix it.
```

```prompt title="Explain a technical request"
Coder, my freelancer suggests [change]. Explain what it means, what could go wrong, and whether it is worth doing.
```

```prompt title="Write down how it works"
Coder, write a short guide for [repository] that explains how to update the content, how the site goes live, and who to contact if it breaks. Put it in the repository as a pull request.
```

> [!NOTE]
> **Checkpoint.** By Friday you have approved a few changes, you can read a plain-language summary, and you know which tasks you are happy to hand over.

## Steady orbit

- **Weekly.** Pick one improvement or fix and give it to the Coder.
- **Monthly.** Ask for a check-up and for updates to anything out of date.
- **After any change.** Look at the site, as house rule 4 reminds you.
- **Every few months.** Revisit your house rules. If it has gone well, allow the Coder to merge tiny edits.

```prompt title="Monthly check-up"
Coder, do a monthly check on [repository]: outdated dependencies, failing checks, broken links, and anything that needs my attention. Give me the top three items and your suggested next step.
```

## Coming soon for your company

- **Accountant:** summarizes the month's expenses, drafts invoices, and writes polite payment reminders. It never sends or charges without your Approve.
- **Marketing:** drafts announcements, emails, and social posts, and holds them for your Approve.
- **Legal:** builds a checklist for your privacy notice and terms, for you and a qualified lawyer to review. It is not legal advice.
- **Product owner:** turns your wish list into tickets the Coder can build.

> [!SOON]
> Ready-made companies are Coming soon. They will set up a whole office, including its house rules, in one go.

## Pitfalls

- **Skipping the explanation.** If you do not understand a summary, ask the Coder to explain it again. That is its job.
- **Approving what you did not read.** Read the plain-language summary on each Approve card.
- **Changing payments or booking first.** Start with text and pages. Take on the sensitive parts after you have built trust.
- **No backups or checks.** If the site has no tests, ask the Coder to add basic ones before you let it merge anything.
- **Sharing secrets in chat.** Never paste passwords or tokens. Connect accounts through Integrations.

---

Source: https://stellarfirm.ai/docs/playbooks/small-business