Proprietary
Log in

Web · Onboarding

Onboarding — for the VA and the client

Two handovers make this system run without Peter or the PM in the loop for routine work: bringing a VA on to run clone sites, and bringing the client on to edit their own copy. Both follow from the workflow and the setup.

Onboarding a VA to run clone sites

The first site is run by the PM, who hardens the workflow page. After that, a VA runs the clones from that page. The VA never builds the template and never touches code.

What the VA needs:

  1. Read access to this proprietary repo (the recipes and the workflow), no write needed.
  2. A Coolify login for the project (deploy, domain, SSL).
  3. A GitHub account, to operate the editor and confirm commits.
  4. The workflow page as the script, plus the PM's run notes from the first site.

What the VA does per site: The delivery half of the workflow: take the site live on Coolify, prove the editing loop end-to-end, connect the tools (GHL with I&Y, Umami, GSC, GBP in-house), run the launch checklist, and onboard the client. Roughly 2 to 4 hours, dropping as it becomes routine.

What the VA does not do: Write copy, build or change the Astro template, or run the first build of any new client. Build errors and code questions go to Peter.

The split that makes the economics work. The conversation and the build (about 1.5 hours of Peter's time) stay senior. The delivery (the VA's 2 to 4 hours) is cheap and repeatable. That is what lets a coach site land near the sub-1k price point.

Onboarding the client to edit their own site

The point of the editor is that the client owns their copy. After this handover, copy questions stop coming to us.

One-time account setup (guided, about 20 minutes)

The client owns and creates their own accounts: the domain, the Cloudflare account, and the GitHub account. This is the price of full ownership and no lock-in, and it is a one-time step. Do not let the client wrestle with it alone.

  1. Book a 20-minute guided session (or a Loom + checklist with screenshots). The VA walks the client through creating the GitHub account, then the Cloudflare account, in order.
  2. Add the team as collaborators on both, so you can deploy and maintain without owning the accounts.
  3. Authorize the GitHub login for the editor together, once, so the consent screen is never met cold later.

The domain is the ownership anchor and stays the client's. Content is portable in git, so even if anything moves later, nothing is lost.

The friendlier login

The editor entry at /admin is a branded page ("Edit your website", one Log in button, reassuring copy), so the client never starts on a developer-looking screen. GitHub's own consent screen cannot be restyled, which is why the guided setup above handles it once. After that, the client's recurring experience is simply: click Log in, land in the editor.

The editing handover

  1. Confirm the client's editor login works (their GitHub account, set up above).
  2. Show the animated walkthrough video (see below) and/or record a short per-client Loom: log in to /admin → change a text → save → check the live site after about a minute.
  3. Walk them through it once live, then let them do one edit themselves while you watch.

The walkthrough video (reusable across clients)

Produce one branded, animated "how to edit your website" video with the SuperStories video method (HyperFrames): a Screen Studio capture of editing in Sveltia, with branded titles, motion, and captions on top. Made once, it is reusable for every coach client, with an optional per-client Loom for anything specific. This is the website system and the video system reinforcing each other.

What to tell the client, in their words:

The framing that protects everyone's time: We sell the basis (positioning, structure, SEO). The client owns the copy. So "can I change this text myself?" gets a confident yes, and that yes is also the boundary: routine copy is theirs, the system is ours.

What we don't do