Skip to content
SiteCrate Docs

Overview

SiteCrate is a Canadian web-design agency operated as a small software system. A prospect fills out an intake form, the work is tracked through an internal dashboard, the client site is built from a shared template, and the client watches progress on a private status page — all backed by one Supabase project.

The moving parts

Section titled “The moving parts”
PieceWhat it isLives at
Marketing sitePublic agency site + client intake + client status trackersitecrate.ca
Admin dashboardInternal control panel — pipeline, revenue, analytics, Build Briefadmin.sitecrate.ca
Client templateTier 1 starting scaffold, cloned once per clientsitecrate-presence (private repo)
Data layerOne Supabase project, two isolated schemas (public / staging)Supabase
EmailTransactional email via Resend, sent from one Netlify functionhello@sitecrate.ca

The lifecycle of a client

Section titled “The lifecycle of a client”
  1. Intake — a prospect submits the form on sitecrate.ca. A row is written to the Supabase projects table through a capability-token RPC, and a confirmation email goes out.
  2. Brief — Ahmed opens the project in the admin and clicks ⚡ Build brief to generate the clone command and a pre-filled Claude Code prompt.
  3. Build — the sitecrate-presence template is cloned per client and built out with Claude Code, then deployed to a {slug}.sitecrate.ca preview.
  4. Review — the project stage moves to review; the client gets an email and reviews their site on the status page, where they can leave feedback or approve.
  5. Launch — once approved, the preview subdomain is swapped for the client’s real domain.

Every public interaction — intake, status reads, feedback, approval — is mediated by SECURITY DEFINER RPCs keyed on a capability token. The public site never touches the projects table directly. See Capability-token RPCs & RLS for why.

Where to go next

Section titled “Where to go next”