Your code needs a copy that doesn't live on your laptop, and a place where the machinery of the next steps can attach to it. That place is GitHub.

Create a free account at github.com/signup (username, email, password — the username becomes part of your project URLs, so pick one you can live with). Then install GitHub's command-line tool gh, which lets you create the repository without leaving the terminal — as of mid-2026 this is the simplest path. On a Mac with Homebrew:

Type this in your terminal, not into the Claude Code chat:

brew install gh
gh auth login   # choose GitHub.com, then login via browser

Windows: winget install --id GitHub.cli in PowerShell, then the same gh auth login. No Homebrew? Installers for every platform are at cli.github.com.

Now connect your project. From inside your project folder, one command creates the repository on GitHub, wires your local folder to it, and pushes your commits:

In your terminal, inside the project folder:

gh repo create salon-booking --private --source=. --push

--private means only you (and people you invite) can see it; --source=. means "use this folder"; --push uploads your commits. Prefer clicking? The web equivalent is the + menu → New repository on github.com, followed by the three connect-and-push commands GitHub shows you afterwards — same result, more typing.

From now on, "push" means "sync my commits to GitHub" — and your laptop is no longer the only copy of anything.

CI is a machine that re-runs your checks on every proposed change, so "the tests pass" stops being a claim the agent makes and becomes a fact GitHub displays. On GitHub, CI is called GitHub Actions, and it's configured by one file in your repo. Ask the agent to create it — this is a file inside your project, which is exactly the agent's job:

Say this inside Claude Code (it's a prompt, not a shell command):

Create .github/workflows/ci.yml with exactly this content,
then commit and push it:

…and give it this workflow (verified against current Actions syntax as of mid-2026 — the @v5/@v6 pins move roughly yearly; if a step fails with a deprecation warning, ask the agent to bump the version):

name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: pnpm/action-setup@v4
        with:
          version: 10
      - uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: pnpm
      - run: pnpm install --frozen-lockfile
      - run: pnpm tsc --noEmit
      - run: pnpm vitest run

Read it top to bottom once, because it's the whole idea of CI in twelve lines: on every pull request and every push to main, rent a fresh Linux machine, fetch the code, install pnpm and Node, install dependencies exactly as pinned in the lockfile, type-check, run the tests. Any step fails → red ✗ on the pull request. As of mid-2026, GitHub's free plan includes 2,000 Actions minutes per month for private repos (public repos are free without limits) — this workflow uses one or two minutes per run, so the allowance is plenty for a solo project.

Now make the green check required, so a red ✗ physically blocks the merge button. On your repo's page: Settings → Rules → Rulesets → New ruleset → New branch ruleset. Name it, set enforcement to Active, target the default branch, and enable Require status checks to pass, selecting the checks job. This is Section 2's hook idea at repository scale: prose asks, machinery guarantees.

Section 8's cheapest form of staging is a preview deploy per pull request: every PR gets its own private copy of the app at its own URL, and merging to main deploys production. Cloudflare Pages gives you exactly that, free, through its Git integration — this is the pipeline half of Section 13's golden-path stack (Vite + TypeScript + Playwright + Cloudflare Pages).

Create a free account at dash.cloudflare.com. Then, in the dashboard: Workers & Pages → Create → Pages → Connect to Git (labels drift; as of mid-2026 this is the flow). Authorize GitHub when asked, pick your repo, and configure the build: framework preset Vite (or set build command pnpm build, output directory dist), production branch main. Save and deploy. That's the entire setup — from now on Cloudflare watches the repo itself.

What you just bought, for nothing: every push to main deploys production at your-project.pages.dev; every pull request gets a unique preview URL, posted as a comment on the PR by Cloudflare's bot and updated on every new commit. The preview is your staging: click through the salon's booking flow there, watch the Section 6 demo reel against it, and only then merge. The free plan includes 500 builds a month and unlimited bandwidth (as of mid-2026) — a solo project rarely uses a tenth of that.

Here's the honest limit of everything above: Cloudflare Pages serves files. A static PWA host runs no server code — and the salon app can't stay static forever, because four of its needs have nowhere to live in a pile of files:

• A database — bookings must exist somewhere that isn't one customer's phone.
• Auth — the owner logs in; customers prove who they are; the browser alone can't be trusted to enforce that.
• API endpoints — server-side code that takes "book Saturday 10:00," checks the slot is really free, and writes it, atomically (Section 7's double-booking gate lives here, not in the browser).
• Background jobs — the reminder email the night before an appointment has to be sent by a machine that's awake when the customer isn't.

The recommended default for beginners, as of mid-2026: Supabase. It's a managed Postgres database with auth, auto-generated APIs, file storage, and scheduled functions bundled — which means one account covers all four needs above, its docs are unusually agent-friendly, and Postgres is the least career-limiting database choice you can make. Two named alternatives, both fine: Neon (excellent managed Postgres, now under Databricks, but database only — you assemble auth and APIs yourself) and Cloudflare D1 + Workers (stays all-Cloudflare and pairs naturally with Pages, but it's SQLite-based and more assembly). If you have no strong pull toward either, take the default and move on — this is a two-way door for a young project, because the domain logic the agent writes ports.

Setup, at orientation depth — the agent does the code, you do the accounts:

• Sign up at supabase.com (using your GitHub account keeps logins simple) and create a New project: name it, pick the region closest to your customers, and save the generated database password in your password manager — this is a real credential, not a formality.
• Wait a couple of minutes while the project provisions, then click the Connect button at the top of the dashboard. That's where the connection strings live — the URL-shaped credential your app's server code uses to reach the database.
• Don't paste it anywhere yet. It goes into the secret stores in step 5 — never into the repo, and never into the chat.

Then, inside Claude Code: "Wire this project to Supabase: read the connection string from the environment variable DATABASE_URL, create the bookings schema we designed, and add the Supabase client for auth." The code is the agent's job; knowing where the credential lives is yours.

You now hold real credentials: a database connection string, API keys. Three rules, one per place a secret might exist:

• Never in the repo. Anything committed is copied to GitHub, to every laptop that clones it, and into every agent context that reads the repo. Locally, secrets live in a file called .env that git is told to ignore.
• In production, secrets live in the platform. Every service has an environment-variables screen: Cloudflare Pages under your project's Settings → Variables and Secrets, GitHub Actions under Settings → Secrets and variables → Actions (labels as of mid-2026). Set DATABASE_URL there once; deployed code reads it at runtime; it never touches the repo.
• Pasted into a chat = burned. If a secret ever lands in an agent conversation, a log, or a screenshot, rotate it — generate a new one in the service's dashboard and retire the old. Agents keep transcripts; treat the chat like a postcard.

Two files make the local side mechanical. .env holds your real values and stays ignored; .env.example holds the names with placeholders and is committed, so future-you (and the agent) can see which variables the app expects without seeing any values:

Say this inside Claude Code:

Add ".env" to .gitignore. Create .env.example listing every
environment variable the app reads, with placeholder values
and a one-line comment each. Confirm .env is not tracked by git.

New machine later? In your terminal: cp .env.example .env, then fill in real values. Windows (PowerShell): copy .env.example .env.

That's the git side handled — but note what it does not do. .gitignore keeps the file out of commits; it does nothing to stop the agent opening the file and reading the credential straight into its context, where a transcript keeps it forever. The line that stops that is a deny rule in .claude/settings.json, from Section 2's permissions step. If you set it up there, the rules are already in place; check them now, because this is the moment the file they protect actually contains something:

File contents — .claude/settings.json (merge into the existing permissions block):

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

Permissions denials can't be argued around — no instruction the model receives, including one smuggled in through data it reads, overrides them. Two honest limits, both covered in Section 2: the rule binds Claude's own Read tool, not a shell command like cat .env (that's what the sandbox and the pre-tool-use hook are for), and it protects the local file only. The copies you pasted into Cloudflare's and GitHub's settings screens are guarded by those accounts, which is the argument for putting a real password and MFA on both.

salon-booking.pages.dev works, but customers trust glowsalon.example more, and you can't print a .pages.dev URL on a gift voucher. A domain is a yearly rental, not a purchase: a .com runs roughly $10–15/year depending on registrar (prices change). Since you already have a Cloudflare account, Cloudflare Registrar is the low-friction choice — as of mid-2026 it sells domains at cost with free WHOIS privacy — but any registrar works.

Pointing it is three ideas: DNS is the internet's phone book, mapping your name to your host; a DNS record is one entry in it; TLS is the certificate that makes it https:// with the padlock. On Cloudflare the whole thing collapses to clicks: in your Pages project, Custom domains → Set up a custom domain, enter the name — if the domain is on Cloudflare, the DNS record is created for you, and the TLS certificate is issued and renewed automatically. Bought elsewhere? The same screen tells you the one record to add at your registrar. No step here involves buying, installing, or renewing a certificate by hand — on modern platforms HTTPS is automatic, and any provider that makes you handle certificates manually is telling you something.

Six steps of clicking got you a working setup, and every one of those clicks now exists only as a memory and a dashboard. Section 8 asks for better: the servers, database, DNS records and project settings should themselves be infrastructure as code — declared in files in your repo, not assembled by hand and remembered by nobody.

The tool is OpenTofu — the open fork of Terraform, and the safer default now that Terraform's licence is no longer open source. Its files describe the infrastructure you want; tofu plan compares that description against what actually exists and prints the difference; tofu apply makes reality match. Pulumi is the equivalent if you'd rather write TypeScript than a config language. All three are formats the agent knows well, so writing the files is its job, not yours.

Install it in your terminal:

brew install opentofu   # Windows: winget install --id OpenTofu.Tofu
tofu version

Now have the agent describe what you already built. This is the gentle way in: you're not creating new infrastructure, you're writing down infrastructure that exists, which means a mistake shows up as a plan that wants to change something — before anything is touched.

Say this inside Claude Code:

Create an infra/ directory with OpenTofu config describing the
infrastructure this project already has:

- the Cloudflare Pages project, its production branch and its
  build settings
- the Cloudflare DNS zone and the records pointing at it
- the Supabase project's settings

Use the cloudflare and supabase providers, pin both to a major
version, and put every credential and account ID in variables
read from the environment — no secrets in the files. Then run
"tofu plan" and show me the output. Do not run apply.

Two housekeeping details the agent will raise. State: OpenTofu keeps a record of what it believes exists, and that file contains secrets, so it does not go in git — start with it on your machine, and move it to a remote backend (Cloudflare R2 and Supabase's storage both work) when a second person or a CI job needs to run apply. Credentials: the API tokens OpenTofu needs are secrets like any other and belong in .env and the platform stores from step 5, never in infra/.

A fresh staging deploy of the salon app is an empty shell — no stylists, no services, no bookings — and you can't test a booking flow against nothing. The fix is a seed script: a program, committed to the repo like any other code, that fills a database with realistic fake data. Committed matters: a fresh environment becomes usable with one command, forever, instead of depending on whoever once clicked test data together by hand.

Say this inside Claude Code:

Create scripts/seed.ts: three stylists, six services, and two
weeks of varied fake bookings — include edge cases (a fully
booked Saturday, an appointment crossing a DST change). All
names and emails clearly synthetic. Add "pnpm seed" to
package.json, reading the target database from DATABASE_URL.

One rule rides along, and it's a gate you'll meet again in the readiness protocol (Gate 57): staging and dev use anonymised or synthetic data — never a raw copy of production. Staging is precisely the environment agents and half-tested code touch most; the day it holds real customers' names and phone numbers, every staging bug is a privacy incident. Synthetic data — invented from nothing, as the seed script above does — is the cleanest answer and costs the agent five minutes. Anonymised data is the other legitimate route, and it's the harder one: a copy of production with every personal field genuinely scrubbed, not merely renamed or hidden by a query. If you ever build a "copy production to staging" script, that scrubbing is the part to verify, because a copy that only looks anonymised fails this gate while appearing to pass it.

The short version: building is free; being depended on costs a little. Rough monthly picture as of mid-2026 — free tiers exist at every layer, prices change, so treat these as ranges to budget with, not quotes: