Proprietary
Log in

Web · Workflow

Workflow — for the PM

How to operate the SuperStories website system day-to-day. Assumes the setup is complete: the Astro + Sveltia template exists and a client site is in a repo. How to onboard a VA and the client is on the onboarding page. Why this is structurally different from WordPress, Webflow, or a templated builder is on the comparison page.

The first site we build is markandreas.com. It is the trial that hardens this page.

What we build, in one line

A fast static website with a simple editor behind it, so the client changes their own copy without touching code. No WordPress, no Webflow. The result loads fast (good for SEO and visitors), is safe (little to attack), and is cheap to run. The same setup is reused for every coach site. markandreas.com is the first.

The four parts you need to understand (not build)

Part In plain terms Who touches it
Astro The site builder. Turns content + design into ready-made, fast pages. Peter (build)
Sveltia The editor. A web page where the client edits text and photos, no code. Client (daily), you (explain)
GitHub The vault. Code and content both live here, with full history. The single source of truth. Automatic
Coolify The server. Publishes the site automatically whenever something changes. You (set up once)

And the tools around it that make it a system, not just a site:

The mental model

This is the whole system in one picture. When the client edits a text, this happens, automatically:

Client edits in Sveltia → GitHub saves it → Coolify rebuilds → live in about a minute.

Nobody touches code. The client types in a form and clicks save. The rest runs by itself. Your job is to turn this on once and then explain it to the client.

The golden rule. You and Peter do not write client copy. The client owns their own text in Sveltia. That is exactly why we chose this setup. When a copy question comes in, the answer is: "that is yours to do in the editor, here is how."

Who does what

Person Role on a website project
Peter Strategy, positioning, SEO basis, and building the Astro + Sveltia structure. Hands you a working site in GitHub.
You (PM) Take the site live, connect the tools, test end-to-end, onboard the client. You guard delivery. You do not write copy.
The client Owns all text and photos in Sveltia. The editor-in-chief of their own site.
I&Y Sets up GHL (form, CRM, calendar). 2 to 3 hours, scheduled with you.
You / a VA Google Business Profile. We do this in-house now, no external party.

Your role: now you, later a VA

Making a site costs little time: about 2 hours once the template exists. One hour of conversation about positioning and content, one hour building in Claude Code. That is the creation, and Peter does it. Your work is the delivery: take it live, connect the tools, test, and hand it over cleanly.

This first time you do more than execute. You prove and sharpen the process. Write down what was unclear while you run it. Those notes improve this page and become the instruction for the VA.

Why you and not an external hire yet: the first time is process design and judgement, with an important client. That belongs in-house. Once the process holds, it flips: you train a VA from this page and you guard quality. You become the owner of the recipe, not the eternal cook. Your real output here is a sharp runbook plus a VA who can run it, not a single delivered site.

What you need before you start

Ask Peter for this access. Without it you cannot start.

The runbook

Work top to bottom. Expect half a day to a day once you have access. Each phase names who runs it and roughly how long.

Phase 0 — Understand the parts (about 30 min, you)

Re-read the mental model. Open the Sveltia admin link Peter gives you and click around without saving, so you see what the client will see. Goal: you understand the rhythm edit → save → live before you switch anything on.

Phase 1 — Take the site live on Coolify (about 30 min, you with Peter)

  1. Peter delivers the working site in the GitHub repo. In Coolify, connect that repo to a new project.
  2. Coolify builds the site and gives you a temporary test link. Open it, confirm every page loads.
  3. Point the domain at Coolify (DNS at the registrar) and turn on SSL (the padlock). Coolify issues the certificate.

The first connection you do together with Peter over screen share. After that you can do it alone for the next site.

Phase 2 — Turn editing on and test it end-to-end (about 45 min, you)

The editor (Sveltia) is already wired to the repo by Peter. Your task is to prove the whole chain works:

  1. Log in to the admin link with your GitHub account.
  2. Change one line of text on a test page and click save / publish.
  3. Check in GitHub that the change lands, and in Coolify that the site rebuilds.
  4. Open the live site and confirm your change is there after about a minute.
  5. Put it back. Now you know the loop is closed.

Phase 3 — Connect the tools (about 2 hours, partly waiting on others)

Phase 4 — Ready for launch (about 45 min, you)

Phase 5 — Onboard the client (about 30 min, you)

This is the most important handover. After it, the client owns their own text and you are no longer called for copy.

  1. Create the client a login for the editor (their free GitHub account, one-time).
  2. Record a short Loom (about 5 min): log in → change a text → save → check the live site.
  3. Let them do it once themselves while you watch. After that they can.

How editing works (to show the client)

The editor shows clean fields per page: a heading, a subhead, text blocks, a photo, a button. The client changes what is in the fields and clicks save. They never see code.

After: the monthly look

Once the site runs, there is one recurring ritual of 30 minutes a month. It answers: who is the client, where do they come from, and what creates movement. The full setup is the MVRP in the client's coach-setup-manual. In short, look at: enquiries this month, top sources (the "how did you find me" field plus Umami), and which one or two activities created movement. Do more of that the next month.

When something looks broken

Rule of thumb. Editing through the editor and setting up the tools: your work. Touching the code: never. That is the line. Hold it and little can go wrong.

What we don't do