This site is built the way we build sites for clients, so it is worth explaining how. The short version: it is static by default. Every page you are reading was rendered to plain HTML when the site was built, not when you asked for it. There is no server assembling pages on demand, no database behind this essay, no application waking up to serve you a paragraph. There is just a file, sitting close to you, delivered fast.
We did not arrive at this for nostalgia. We arrived at it because it is the simplest thing that meets the bar, and the simplest thing that meets the bar is almost always the right thing.
What static buys
A static site is fast in a way that is hard to undo. There is no work to do before the page appears, so it appears. It is cheap to host, because serving a file is the easiest thing a network does. It is robust, because there is less to break — no runtime, no server process, no moving parts to fall over at 3am. And it is trivially cacheable, so it can live at the edge, a few milliseconds from the reader, anywhere in the world.
It is also good for search. Indexable HTML, clean URLs, a real sitemap, correct metadata — these are the things a search engine wants, and a static site hands them over without effort. This essay, for instance, is its own URL with its own title and description, generated at build time. The machine reading it does not have to run any JavaScript to find out what it says.
The stack, briefly
The site is built with Astro, which renders pages to static HTML and ships almost no JavaScript by default. That default is the whole point. The web’s performance problem is mostly JavaScript that did not need to be there, and the cure is to not send it.
Where we do want interaction, we use small Svelte components that hydrate only where they appear — Astro calls these islands. We hold ourselves to a hard budget: a tiny, declared set of them, no more. The home page has one cinematic moment; a few touches live elsewhere; everything else is static. The interactivity is concentrated, not sprayed across every element. Concentrating it is what keeps the site fast, because the parts that do not need to think simply do not.
The route transitions — the soft wash of colour as you move between rooms — use the browser’s own View Transitions, not a framework. That is one less thing to ship.
Deployed as static assets
The built site is a folder of files, and we deploy it to Cloudflare’s static assets on their Workers platform. There is no application running there. Cloudflare serves the files from the edge, close to whoever is reading, and that is all the infrastructure this site needs.
The domain is not baked into the build. It is supplied at deploy time through a single environment variable, and everything that needs an absolute URL — the canonical tags, the social previews, the sitemap — is generated from it. The same build can ship to a test address or a real one without changing a line of code.
Why “by default”
We say static by default, not static always, because the default is a starting position, not a dogma. Some projects genuinely need a server doing work at request time, and when one does, we add exactly that and no more. But we start from static and make the project earn its way to anything heavier. Most of the time, it never needs to.
That is the discipline behind everything here. Fewer pages. Fewer dependencies. Less JavaScript. Less infrastructure. Not because less is a virtue in itself, but because what remains, when you have removed everything that did not earn its place, is fast, durable, and finished — which is exactly what a website should be.