← Prototypes · Index

The setup, step by step

What the operator's session does for a new customer, in order. About an hour the first time, twenty minutes by the tenth.

1. The repository

• Create a public repository under the customer's own GitHub account (create the account with them on the call if they do not have one; it is theirs, not yours). Name it after the domain: example-bakery-co-uk.
• Add the operator as a collaborator. The customer owns; the operator works.
• Initialise with README.md, PLAYBOOK.md (from the template), CHANGELOG.md, and a .gitignore.

2. The site

• Plain HTML with one shared stylesheet, or a very small static generator the agent can maintain. Plain HTML is the default; it has no build to break.
• One file per page under pages/, the home page at index.html, images under images/, the brand assets (logo, colours, fonts) under assets/brand/.
• site.json holds the structured content the pages repeat: name, address, hours, phone, social links. Pages read it at build or the agent keeps them in step; either way there is one source for the facts that change most.
• Every template ships with privacy.html, accessibility.html and a no-cookie posture. No analytics unless the customer asks and the playbook records it.

3. The branches

main       the live site
preview    what the customer looks at before it goes live

Protect main so that only the operator and the customer's own account can push. Set the default branch for the customer's session to preview for anything the playbook marks as needing a look.

4. The deploy

• GitHub Pages, source: GitHub Actions. The standard static deploy workflow, unchanged.
• Two environments: main to the production Pages site, preview to a second Pages deployment or a preview host. If Pages will not deploy two branches for this account, the preview branch deploys to a bucket behind a CDN or to Netlify; the files are the same.
• Confirm the deploy runs on push and the site is up before touching the domain.

5. The domain

• The customer owns the domain and pays for it. If they do not have one, register it in their name, not yours.
• CNAME (or A records for the apex) pointing at GitHub Pages, set at the customer's registrar. Enforce HTTPS in the Pages settings once the certificate is issued.
• preview.<domain> as a CNAME to the preview deployment, if the customer wants a friendly preview address.

6. The agent

• The operator's session: a project with the repository connected and the playbook loaded.
• The customer's session: a separate project under the customer's own account, with the same repository connected and the playbook loaded, and a one-page guide on how to ask for a change.
• Test both: make a content change from the customer's session and watch it go live; ask for a layout change and watch it go to preview.

7. The vault

• Create the customer's vault: the setup notes, the materials they sent, the brand pack, the playbook, and the handover page. Commit, push, and give the customer the read key.
• The customer now holds everything: the repository, the domain, the vault. Say so in the handover.

8. The checklist, to keep in the operator's vault

• [ ] Repository public, under the customer's account, operator as collaborator
• [ ] PLAYBOOK.md filled in, every blank
• [ ] privacy.html, accessibility.html present and correct for this business
• [ ] Images resized; no phone originals committed
• [ ] main protected; preview deploying
• [ ] Domain pointed, HTTPS enforced
• [ ] Customer's session tested with one live change and one preview change
• [ ] Customer vault created, read key handed over
• [ ] First line in CHANGELOG.md: "Site launched"
• [ ] Setup time recorded

← Prototypes · Index