CS-18 // Dossier
Replicable studio website + CRM template
A server-rendered marketing and booking site wired directly into the studio’s CRM — the CRM stays the system of record, the site is a thin validated layer — then generalized into a fork-per-client template: a single completed intake doc plus a nine-phase build produces the next studio’s live site.
Exhibit // CS-18
R-02 · interface redrawn from the live build — zero client pixels
- Client
- R-01SEALED UNDER NDA. SPECIFICS WALK THROUGH LIVE. → BOOK
- Industry
- Martial-arts academy · same client as CS-01, via agency
- System
- Replicable studio website + CRM template
- Stack
- Astro · Vercel · GoHighLevel · Tailwind · Playwright
- Trigger
- An ad click — or the agency signing its next studio
- Metrics
- System scope
01 // The problem
The agency needed this site live for one location, then the same system for the next locations without rebuilding it each time. And the studio’s staff had to be able to change trial deadlines, prices and copy without a developer or a redeploy.
02 // The system
Redrawn — no client data
The system
03 // The delta
Before and after go-live
Before
- One studio needing a site; every next studio needing a rebuild
- CRM calls scattered wherever they were needed
- Copy and deadline changes queued behind a developer
- Handover as a phone call, not a document
With the system
- A fork-per-client template: intake doc in, live site out
- One orchestrator module owning every CRM call
- Staff edit settings in the CRM; the site follows, no redeploy
- A system report + owner’s handbook, audited before handover
04 // What got done
7 entries
- B-01Built 26 pages and 17 endpoints server-rendered, including six channel-specific ad landers so paid traffic lands on copy matched to its source
- B-02Funnelled every CRM call through a single orchestration module — rate limiting, idempotency, webhook secrets and signed tokens as dedicated helpers, not scattered calls
- B-03Kept every staff-editable setting in the CRM rather than in env vars — staff change deadlines and copy from the CRM, and the site follows without a redeploy
- B-04Built a self-service rebooking flow (lookup, change program, add a family member) plus four inbound CRM webhooks keeping site and CRM reconciled in both directions
- B-05Generalized the build into a 21-document replication kit: a 13-part client intake questionnaire, nine phases with three human sign-off gates, and seven non-negotiable rules — never invent missing inputs, stop on any failed phase, never auto-promote to production
- B-06Audited before handover: three parallel adversarial browser agents (network leak, bundle scan, form abuse) plus a five-area QA pass
- B-07When bookings later faltered, ran a five-day diagnostic producing a 17-finding register with five root causes — and a published corrections log withdrawing its own earlier claims
05 // Outcome
System scope — capability metrics, honestly labeled
- → Scope
pages · 17 endpoints, live on the studio’s domain - 0
- → Scope
build phases from intake doc to a new studio live - 0
- → Scope
operator CLIs shipped with the site - 0
06 // The result
From the build log
- Live on the studio’s domain, handed over with a system report and a non-technical owner’s handbook
- A new studio site = a single completed intake doc + a nine-phase build, with tooling the operator inherits
- Every finding of the booking diagnostic traced to a root cause on the record
Want a system like this one?
Free · 30 min · leave with a rough scope either way