Docu­mentation.

Static hosting on cPanel

Every static site we build is plain files. There is no build step on the server, no Node process to keep alive and nothing to restart. Upload the folder and it is live.

# from your machine, in the project folder
rsync -avz --delete \
  --exclude 'tools/' --exclude '*.md' --exclude '.git' \
  ./ user@yourhost:~/public_html/

# or, with no shell access, upload the same folder in cPanel File Manager

What .htaccess is doing

Four things: forcing HTTPS, collapsing www to the apex domain, redirecting /page.html to /page so the extension leaves Google’s index, and serving page.html when someone asks for /page.

RewriteEngine On

# /page.html -> /page  (301, so the extension drops out of the index)
RewriteCond %{THE_REQUEST} \s/+(.+?)\.html[\s?] [NC]
RewriteRule ^ /%1 [R=301,L]

# /page -> page.html  (internal, the address bar stays clean)
RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^(.+?)/?$ $1.html [L]

How a workflow is put together

Every workflow we build has the same four parts, whichever platform it runs on. If you can name these four things, you can maintain it.

• Trigger — what starts it: a form, a webhook, a schedule, a new row
• Guard — the check that stops it running on bad data
• Actions — the steps, in order, each one independently retryable
• Alert — where it shouts when a step fails twice in a row

A webhook receiver, in full

export async function handler(req, res) {
  // 1. guard — verify it really came from the sender
  if (!verifySignature(req.headers['x-signature'], req.rawBody)) {
    return res.status(401).json({ ok: false });
  }

  // 2. guard — have we already handled this exact event?
  const seen = await store.get(`evt:${req.body.id}`);
  if (seen) return res.status(200).json({ ok: true, duplicate: true });

  // 3. act
  await createInvoice(req.body.order);
  await notifyChannel(`Invoice raised for ${req.body.order.ref}`);

  // 4. remember, so a retry is a no-op rather than a second invoice
  await store.set(`evt:${req.body.id}`, 1, { ttl: 60 * 60 * 24 * 30 });
  return res.status(200).json({ ok: true });
}

What the agent is allowed to do

An agent is defined by three lists, and all three are yours to edit: the sources it may read, the actions it may take, and the conditions that force a handover to a person.

{
  "name": "Front-line support",
  "sources": ["help-centre", "shipping-policy", "returns-policy"],
  "actions": ["answer", "check_order_status", "start_return"],
  "escalate_when": [
    "customer asks for a refund above 100",
    "customer is upset",
    "question is not covered by sources",
    "customer asks twice for a human"
  ],
  "tone": "plain, short sentences, no exclamation marks"
}

Keeping answers current

The agent reads your documentation rather than a frozen copy of it. Change a help article and the next question is answered from the new version — there is no retraining step and no separate content to maintain.

What you receive at the end

Handover is a deliverable with its own checklist, not an email saying “all done”. Every project ends with all of this:

• Source code in a repository you own, with its history intact
• Design files, exported and editable
• Every account transferred into your name — hosting, domain, ads, analytics
• A written document naming every moving part and where it lives
• Environment variables and credentials, delivered through a secret link rather than email
• A recorded walkthrough of anything with more than three steps