How this site works
The site is a Git repository that compiles to static HTML. GitHub is the CMS, an hourly build publishes future-dated posts on its own, and nothing ships JavaScript except search.
Every page on this site is a plain HTML file. There’s no server to patch, no database to back up, no admin panel to defend. The whole thing is a Git repository that compiles into a website, and the reasoning behind that setup matters more than the stack itself.
Git is the CMS
The site runs on Astro 7 and builds to fully static output. Every piece of content is one markdown file in a content folder. One file per essay, one per case study, one per book in the library, one per social post in the feed. Publishing means adding a file. Fixing a typo means editing one. I can do either from github.com or from the GitHub mobile app on my phone, which makes my CMS a tool I already trust, already version, and already know how to review.
That sounds spartan until you live with it. Every change is a commit, so the site carries its own history. Drafts can sit on branches. The only thing between me and a published fix is a commit message.
Publishing runs itself
When a commit lands, GitHub Actions builds the site with npm ci and deploys it to GitHub Pages over OIDC. That detail matters more than it sounds. OIDC means the workflow proves its identity to GitHub at deploy time, so no long-lived deploy secret exists anywhere, and a secret that doesn’t exist can’t leak. An hourly rebuild finishes the job. If I date a post in the future, the next scheduled build picks it up and the post publishes itself while I’m doing something else.
The same caution runs through the dependencies. npm install scripts are blocked by default through a strict allowlist in .npmrc, new releases wait out a Renovate cooldown before they’re considered, and every CI action is pinned to a commit SHA rather than a tag. None of this is glamorous, and that’s roughly the point. Most of what goes wrong with websites comes from moving parts nobody was watching.
Nearly zero JavaScript
Every page ships without client-side JavaScript, with one exception. Search runs on Pagefind, self-hosted, and its script loads only on /search/. Everything else is HTML and CSS, so pages stay fast on hotel wifi, keep working with scripts disabled, and have very few ways to fail. I like that you can read every page here without running a program.
How it looks
The palette is a soft blue-grey with a little teal in it, closer to fog than to paper, and each section gets one bright accent. Orange for services, teal for work, purple for topics, green for the feed, gold for the library. The accents work as wayfinding rather than decoration. When the nav underline goes green, you’re somewhere in the feed, and that’s all it has to do. The type is self-hosted. Fraunces, a serif, carries the headings and long-form text like this essay, and I leave its wonky letterforms switched on for page titles. Archivo handles the interface, and Fragment Mono takes the small labels.
The art draws itself
There isn’t a stock image anywhere on the site. Each card’s artwork is a stack of gradients seeded per entry, tinted in its section’s colour, drifting slowly, with a layer of grain on top so it looks printed instead of plasticky. Every essay, book, and post gets its own composition. If your system asks for reduced motion, the gradients hold still. There are no tracking scripts and no cookies either. I never found a use for them that served a reader.
What I kept out
I work with AI agents every day and I built this site with their help, which is exactly why it can’t be allowed to look like the median AI-generated page. The repo’s planning docs include a literal banned-patterns list. No electric blue, no blue-to-purple gradients, no glassmorphism, no cards fading up as you scroll. The trouble with those patterns is that they’re defaults, and defaults are how a thousand sites end up looking the same.
Mostly these choices trade cleverness for durability. Markdown will outlive whatever platform is fashionable this year, and static files will outlive frameworks. A site with this few moving parts is one I’ll still enjoy maintaining in five years, and one that should keep working even when I’m not looking at it.