What's the publishing workflow?
Copy a template, write the content, run python3 tools/og-images.py to generate the page's share card, then node build.mjs. The build mirrors src/ into public/, and the page automatically appears in its section index, the home feed, and llms.txt. There's no CMS and no database — the filesystem is the content model.
Being machine-readable — llms.txt, clean HTML, all AI bots allowed — is basic hygiene that many competitors skip. It's also something we can help clients with directly.
What does the build generate?
From each page's title, description, and path it derives the full SEO head — canonical URL, Open Graph and Twitter tags, robots directive, favicon, and a JSON-LD @graph with the right schema type. Across all pages it writes three machine-facing files from the same metadata so they never drift: llms.txt (a markdown map for models), sitemap.xml (every indexable page with a last-modified date), and robots.txt (which welcomes the major AI crawlers and points to both). It also fills the home page's latest-content feed. The assembly mechanics are in Architecture & build system.
Why are the links relative?
We author links as root-absolute (/guides/x.html) because that's simple and depth-independent, but the build rewrites them to page-relative paths (../guides/x.html) on the way out. That makes the whole public/ folder portable — it works served from a domain root or any subpath, and previews without special configuration. The URLs that must stay absolute — canonical, og:url, the sitemap, and robots — do, driven by the domain in site.config.json.
How are the share images made?
A small Python script renders a branded 1200×630 card per page using the site's colors, pulling each page's headline and section label so the card reads well. It also emits the default card and the logo. Running it is a separate step from the build because it needs image libraries the build doesn't — keeping the core build dependency-free.
How does local development work?
You can serve src/ directly and a tiny client-side loader fills the shared header and footer at runtime, so you preview without rebuilding. The production build does the same inlining ahead of time and strips that loader. Same pages, two assembly moments — fast feedback in dev, complete HTML in prod.
How do we deploy?
Commit and push. A static host builds with node build.mjs and serves public/. Because the links are relative, it doesn't even have to be the web root — it works under any path. No servers to run, no runtime to patch; rolling back is just redeploying a previous commit. This is what makes the whole site cheap and durable.
The short version
One build script does assembly, SEO, structured data, llms.txt, sitemap, robots, relative links, and the feed; a separate script makes the images; everything ships as static files. Small toolchain, no moving parts, complete output.