Delivery Playbook: The Repaint Recipe & Scope Ladder

How we actually build and ship a client engagement — the repeatable recipe, staged so we can serve a client who wants a little or a lot. Operational playbook — derived from Business model + DECISIONS.md (settled) + Brand strategy.

The recipe in one breath

We have one recipe with five optional, separately-priced stages. The spine: take the client's current site and rebuild it faithfully on a modern stack — same look, same content, but faster, mobile, and owned — then offer to go further only if the client wants to. Different clients want different amounts of work, so each stage is a deliberate yes/no with its own price.

Stage 0  Discovery / Signal Audit   →  the opportunity map (+ optional on-spec preview)
Stage 1  Faithful Repaint  ★DEFAULT  →  the existing site, rebuilt 1:1 — this is the Repaint package
Stage 2  Options round               →  auto-generated theme/component variants; client picks a direction
Stage 3  Rebrand        (optional)   →  new identity grounded in the client's OWN material
Stage 4  Full redesign  (optional)   →  new IA / structure / new pages, not just a reskin
         ── Handover & Launch ──     →  wire the editable CMS, launch checklist, hand over, → Care Plan

Stage 1 alone is the R28,000 Repaint. Everything above it stacks on top and is quoted before it starts. Everything runs under the hard concurrency cap: one active build + a waitlist (see Concurrency & scope discipline).

Stage table

Client-facing deliverables use outcome language only — never name the stack to a client (internal recipe is the appendix). Hour figures are targets to validate on clients 1–3 (BUSINESS-MODEL has no hours-per-client data yet; M3 KPI is to measure them). They are incremental Daniel-hours for that stage.

Full-ladder engagement (0→4) ≈ 55–70 all-in hrs — that is a peak-deal, not a typical job (aerias was exactly this: repaint + rebrand + full redesign). It is governed by the concurrency cap and must be quoted as a bespoke build, well above the R28k anchor.

Stage detail

Stage 0 — Discovery / Signal Audit

• Deliverable: the 2–3 page opportunity map with the client's own before/after numbers (load time, mobile behaviour, lost enquiries, what's worth keeping). ~5-day turnaround. This is a paid product (Pkg 0), not a free sales call.
• Also capture here: all content, IA (page/nav map), brand assets, photos, logins, domain/DNS ownership, current host, current enquiry/booking flow, integrations.
• On-spec preview (optional): for a cold lead with a visible defect, build a small slice of their rebuilt site up front as the sales asset (mozguide, physioscpt are the on-spec-preview prospects). This lives in the acquisition process — see Acquisition & intake; the free 2-min WhatsApp "what's worth keeping" look and the paid audit must be stated explicitly and never ambush each other.
• Start the clock: time-track from client 1 (M1 KPI) — every hour on every stage.

Stage 1 — Faithful Repaint (the default / hero)

• The rule: clone the original's look verbatim first. Rebuild the existing site so it looks exactly like the old one — same layout, same copy, same imagery — only faster, responsive, and owned by the client. No creative liberties at this stage.
• Worked example: mozguide "Option B" — a faithful clone of the original mozguide.com (classic teal + gold Wix look, serif type, flag wordmark, verbatim original copy), built as a parallel branch/preview. That is the Stage-1 shape: reproduce, don't reinterpret.
• Scope boundary (Pkg B): reuse content/IA, ≤10 pages, 1 revision round, 2–3 weeks.
• This alone is the sellable, complete engagement — most Repaint leads should stop here.

Stage 2 — Options round

• After the faithful clone exists, auto-generate variants and let Daniel/the client choose a direction, then build the chosen one. Three mechanisms, all already in the template:
  1. Multi-concept render panel — several full design concepts rendered on the real content (mozguide shipped a 3-concept panel; the client picked one).
  2. Curated theme layer — theme.json's 5 colour roles + heading/body font, flippable without touching components, so palette/type options are cheap to present.
  3. Interactive click-through switcher — a live switcher on the client's real content rather than static mock-ups (the standing default for taste choices).
• Visual calls are the client's/Daniel's — present options, don't batch-decide.
• Pricing is Proposed (see Open decisions): a light "pick a palette/type direction" is inside the Repaint's revision; a deeper multi-concept exploration is a paid add-on.

Stage 3 — Rebrand (optional)

• New visual identity, but grounded in the client's own material — derive the palette from their photos (k-means), build from their story. Fresh components per brand.
• Do NOT reuse danielslater.dev's house style (capsule header, waterline footer, mono kickers, warm-sand ground, editorial serif). It reads as a reskin — mozguide was rejected twice for being "too close to danielslater.dev" even after re-theming; the tell was shared structure/components, not colour. Start each brand from a clean slate; default to simple, clean, airy unless the brand says otherwise. danielslater.dev is only ever the incidental preview host (<client>.danielslater.dev).
• Worked example: aerias got a full rebranding step — that is Stage 3.

Stage 4 — Full redesign (optional)

• New information architecture, new page structure, new pages — a rethink of how the site works, not just how it looks.
• Worked example: aerias also got a complete full redesign — that is Stage 4.
• Pkg B explicitly carves this out ("full redesign = bespoke quote"), so it is always a bespoke line, never bent into the R28k Repaint.

Handover & Launch

Wire the editable CMS (internal recipe in the appendix): Sveltia git-CMS at /admin, staging branch editable → merge to main = publish. Then run the checklist:

• Remove noindex (was on for the private preview) — site is now indexable
• Custom domain + SSL live (proxied CNAME in the client's zone)
• Analytics on — Cloudflare Web Analytics (the settled pick) on the live site
• Contact / enquiry channel live — WhatsApp click-to-chat above the form for SA; email fallback; POPIA opt-in wired for health/professional practices
• CMS auth working (CF Access + OAuth worker) or the redeploy path documented if it's a direct-upload preview site
• Ownership handover — repo access, domain/DNS, code ownership, and a short written handover doc. "You own everything" is a settled brand promise; make it literally true
• Transition to a Care Plan — best-effort month-to-month + optional Chat attach (WhatsApp Receptionist). See Care Plan & recurring

NO same-day go-live if WhatsApp is in scope: Meta Business verification is 2–14 days

• template review + a dedicated number. Set this expectation pre-signature.

Decision tree — which stages to propose

Read the lead's current site + goals + budget, then propose the shortest ladder that solves the actual problem. Always propose Stage 0 first for a paying lead.

Upsell direction rule: always upsell to the next stage, never bend the current one. "Repaint + you want it re-organised" is a Stage-4 quote, not free scope inside Stage 1.

Concurrency & scope discipline

Concurrency cap (settled — Risk #2 mitigation): ONE active build + a waitlist. Daniel is ¼–½ a full-timer's throughput; there is no Designjoy turnaround promise. Never quote a timeline that assumes two builds in parallel. A second signed client waits; Storefront is "occasional big fish", not a monthly.

Revision / change-order boundary (settled — Risk #3, scope creep = the #1 failure mode):

• Every build package includes exactly one revision round on the agreed scope.
• Anything off-scope is a change order at R900/hr SA · $110/hr INTL — quoted in writing and approved BEFORE any work starts. No silent absorption.
• The paid Signal Audit exists partly to write scope down first so "off-scope" is unambiguous later.
• Via an agency (ICP-C): the agency owns the client and will negotiate scope you can't police — contract that all scope changes route back to Daniel for re-quote in writing, and keep the hosting/retainer layer as the anti-capture moat.
• No hospitality clients, ever (employer separation) — never route a hospitality lead into any stage; the restaurant app is anonymised capability proof only, never a seed.

Appendix — Internal Standard Tech Recipe

Internal only. Client language stays stack-agnostic and outcome-led. This is the "Option A" editable-site template — the default for a marketing/brochure site.

Stack

• SvelteKit (Svelte 5 runes, TS) + adapter-static, 100% prerendered → Cloudflare Pages.
• Content = JSON in the repo (src/lib/content/*.json) with thin typed loaders (content.ts / site.ts). Sveltia can only edit JSON/YAML/MD — never .ts — so all editable content lives in JSON.
• Curated theme layer: theme.json = 5 colour roles + heading/body font → theme.ts builds a :root token override injected in +layout.svelte (the sole source of those tokens). Fonts self-hosted (fontsource), data-driven and flippable. This layer is the Stage-2 options mechanism.
• CMS = Sveltia at /admin (static/admin/index.html + config.yml), GitHub backend.
• Branch model: staging = editable (CMS commits land here → staging rebuilds), main = prod, publish = merge staging → main.
• Auth: Cloudflare Access gates /admin + staging; CMS GitHub OAuth via a sveltia-cms-auth Cloudflare Worker (needs a GitHub OAuth app). CMS mode needs Pages git-integration (main→prod, staging→preview); a preview-only site can run direct-upload via wrangler pages deploy instead (no auto-redeploy on push — document it).
• Fresh components per client brand — never reuse the danielslater.dev component set (it reads as a reskin). Reuse the stack/architecture, build the visual components fresh.
• Animated background (optional signature): the "tiny agents" canvas template (surfers/starlings/runners) — read the handover contract first; pre-roll before first paint + prefers-reduced-motion static frame are mandatory; verify with headless screenshots.
• Noindex via static/_headers during preview; remove at launch.

Per-client reuse: fork the template repo → swap content JSON + photos + palette tokens → make 2 Pages projects + branches + domains.

Graduation trigger: the moment a client needs bookings / logins / inventory / payments, leave the static "Option A" template and move to the aerias direction (D1 / Supabase + Edge Functions, hosted checkout). That is a Storefront (Pkg C) engagement, not a Repaint.

Verification (every build): npm run check + build green before handover; visual pass (screenshots) after non-trivial layout work; animated backgrounds get the headless-screenshot

• pointer-assertion + fps checks from the tiny-agents template.

Open decisions (→ DECISIONS.md)

Flag these to Daniel to ratify; none is asserted as settled here.

• Stage 2 "Options round" as a discrete priced add-on. No package exists for it in BUSINESS-MODEL. Proposed: a light palette/type pick is folded into the Repaint's one revision (no extra charge); a deeper multi-concept exploration is a paid add-on (Proposed price ~R4,500 / ~$350, or billed at the R900/hr shadow rate). Needs Daniel's price call.
• Per-stage hour targets for Stages 2–4 (+4–8h / +8–16h / +12–20h incremental). These extend the package-level unit-econ figures (which only cover Pkg 0/A/B/C); they are estimates to validate on clients 1–3, not measured.
• Free automated audit as a top-of-funnel feeder into the paid Signal Audit (Kea Logic runs one; already an open question in PROSPECTS.md). Stage 0 stays the paid audit until Daniel decides — noted here only because it changes the front door of this ladder.