The rule behind the line: the kit is everything that can live in your repository. The platform is anything that needs state held somewhere else: a record of people and conversations, your analytics history, an agent that acts on both.
What the kit is
The Saprel Site Kit is the open-source template every Saprel Web site is built from: plain HTML, CSS and JavaScript, a small Cloudflare Worker for the contact form, the checks that gate a launch, and the documents that tell a coding agent how to build and keep the site. It is MIT licensed. The kit is maintained by Saprel. It is public for three reasons, and the first two are self-interested. It is how we build sites ourselves, so it has to be good. People who find it useful may one day want the platform, and we would rather earn that with working software than with a brochure. And the way this kind of site gets built (a written spec, plain files, an agent that follows both) is better when more people use it, break it and say so. If you use the kit and never use Saprel, that is the kit working as intended. Issues and corrections are welcome; how we handle contributions is in the repository's CONTRIBUTING.md.
Repository: https://github.com/saprel-labs/site-kit. Setting one up, step by step: https://saprel.com/web/setup-guide.
What's in the kit, what you add, what the platform adds
| You need | In the kit | You add it yourself | The platform provides |
|---|---|---|---|
| A strategy the site is built from | The slot where it lives, an outline to write your own, and docs that cite it | Your own brand and positioning work, in any form | Saprel Guide produces the go-to-market strategy and the homepage mockup |
| Pages built and kept consistent | Templates, the site spec, the shared-block check, screenshots, launch checks | Nothing | Nothing |
| Hosting and deploys | Worker config, deploy command, redirect and header files, launch checklist | A Cloudflare account (or another host, above) | Nothing. The platform does not host your site or hold your DNS. |
| A contact form | The form, spam gates, a lead screen, and three independent forwards: a Google Chat or Slack webhook, your CRM's form endpoint, and a submission store | A webhook URL or a CRM endpoint. For a store: anything that accepts the documented, versioned intake contract (docs/site-config.md, Forms) | Stores each submission, matches it to a person you already know or stages a new one for you to confirm, and posts a short follow-up. A person confirms; the agent does not decide who is a customer. |
| Tracking and conversion events | Zaraz setup, event naming, consent stance, the day-one export checklist (exports are forward-only, so this matters even if you never use the platform) | Your own analytics accounts | Delivers the exports into a dataset that is yours, under one named service account you add and can remove in one row |
| Knowing how the site is doing | A monthly search and answer-engine review runbook you or your agent can run; baseline-before-rework | The time to run it | A weekly read of the same data with alarms when something moves (next) |
| A record of what changed | The change-report convention: impact classes, what-changed-and-why commits | Nothing | Generated change reports, delivered alongside the weekly report (next) |
| Editing without a developer | The block-id convention that makes it possible later | A coding agent and git | Self-service edits, and new pages from templates: a blog post or case study drafted from your own material (next) |
| Secrets | A convention: scripts read environment variables or stdin only; any injector works (docs/setup-guide.md, Secrets) | A secrets manager of your choice | Nothing. The platform never holds your site's secrets; a platform site holds one key that lets it submit forms, and the platform stores only that key's hash. |
| Help when something breaks | The runbooks, the troubleshooting section, and the issue tracker (best effort, no guarantee of a reply) | Your own operator or developer | Support for the platform's own services. It does not operate or fix your site; an operator does. |
Why the kit is built this way
These are design choices, each with a cost. The reasoning and the rejected alternatives are in docs/decisions/.
- No CMS. The site is files in a git repository, and the editor is an AI coding agent reading a written spec (
docs/site-config.md). A CMS exists so that people who cannot edit code can change a site; an agent that can read a spec and edit HTML removes that reason, and with it the database, the plugins, the login page and the upgrade treadmill. Cost: someone has to be comfortable working with a coding agent and git, or hire someone who is. - No framework, no build step. Plain HTML, CSS and JavaScript. There is no compile step to break silently, every page is readable as it ships, and an agent can reason about the whole site. Cost: shared markup (nav, footer) is duplicated across pages and kept identical by a check that fails the build when they drift, rather than by components.
- Docs are the spec. What the site should say lives in
docs/; the pages are generated from it and checked against it. A change in positioning is one change to the spec, not a page-by-page hunt. Cost: the discipline of changing the spec first. - Fast by construction. Static files on an edge network, self-hosted fonts, no client-side analytics script. There is little to optimise because little is loaded.
- Gates over guidance. Where a mistake is expensive and cheap to catch (a
noindexsurviving launch, a redirect loop, a half-configured form), the kit ships a script that fails, not a paragraph that advises. - Adding capability means adding files. A new page type is a template and a spec block. A form is a small worker and a documented contract. Where a setting has to live in a vendor's dashboard, the repository records what it is.
What you are tied to, and how to leave
The kit makes four vendor choices. None is required by the approach; each is the default because it was the best fit on the sites the kit was drawn from.
| Choice | What it does here | If you would rather not |
|---|---|---|
| Cloudflare Workers (static assets) | Hosts the site; runs the form handler | The site is static files: any static host serves public/. The form handler is one small worker using mostly standard web APIs; moving it to another runtime is a small port, not a rewrite. |
| Cloudflare Turnstile | Bot gate on the form; the form refuses submissions without it | Another challenge service: one verification function in the worker. |
| Cloudflare Zaraz | Loads analytics server-side | A documented direct-tag fallback ships in the kit (docs/decisions/0002). |
| Google Analytics, Search Console, BigQuery exports | Measurement and its history | Two setups are maintainer-tested and documented: Google Analytics through Zaraz, and cookieless Piwik PRO (docs/decisions/0004). Others are compatible: the tracking wrapper (track() in site.js) is the only place events are named, so point it at the tool you use. The exports matter only if you want your own history in a warehouse. |
What you are not tied to: a CMS, a page builder, a proprietary template language, a hosted editor, or Saprel. Your repository is the site. If you stop using every service named on this page, you still have working HTML.
What the platform does not do
It does not host your site, register or hold your domain, log in to your Cloudflare account, write to your analytics, or edit your repository without a change you can see in git. It does not operate sites: an operator (you, an agency, a fractional marketer) does that, with the kit. What it holds for a site is the minimum it needs for the services you turned on, and removing its access is one step per source: a row in a user list, or one deleted key.
Your site and your tools produce evidence: a form submission, a meeting, an email thread, a search trend. The platform captures that evidence in a record of the people and organisations you work with. An agent reads the record and does the clerical work around it: matching a new submission to someone you know, noticing that a page's traffic fell, drafting the follow-up you would otherwise forget. It proposes; a person commits. Everything it concludes is traceable to the evidence it came from. The kit is how the website becomes one of those sources instead of a separate island of analytics.
Get started
Clone the repository or use it as a template, then follow the setup guide at https://saprel.com/web/setup-guide from an empty repository to launch. A problem with the kit is an issue on the repository; how contributions are handled is in the repository's CONTRIBUTING.md, and a security concern goes to the address in its SECURITY.md, never a public issue.