Colophon

    Built the way I say things should be built.

    A colophon is the page where a site explains how it’s made. Most of my writing argues for boring foundations, working software, and judgment over hype — so it seemed fair to apply the argument to the site itself. This is what coreywall.com is made of, why it’s made that way, and where AI fit in.

    Static first

    The site is a Vite + React app deployed on Vercel, and it’s static-first: every public page is prerendered to real HTML at build time. There’s no framework doing that for me — no Next.js — just a custom script, about eighty lines of react-dom/server, that renders each route and writes the file. The payoff is unglamorous and constant: posts unfurl with the right title and preview when you share them, every page is readable before JavaScript loads (or without it entirely), and a CDN does nearly all of the serving.

    The only live backend is two small serverless functions. One counts views per post — Upstash Redis, deduplicated per IP — and the other handles login and saves for the admin editor. Everything else on this site reaches you as a static file.

    Content is just files

    There’s no database. The homepage bio and work history are markdown files. Blog posts are MDX with a small set of custom components: callouts, feature quotes, video embeds, footnotes. At build time, a script parses all of it and emits a static-JSON “API”, a sitemap, and the RSS feed. The same parsers run in local development, so what I preview is exactly what ships. Content lives in git next to the code that renders it — fixing a typo is a diff, not a migration, and there’s no content server anywhere that has to stay alive.

    Publishing is a commit

    Publishing a post is a git commit. That’s the whole pipeline. There’s a password-gated admin editor for writing away from my desk, but even it doesn’t talk to a CMS — it saves by committing through the GitHub Contents API, which kicks off Vercel’s normal rebuild. Git is the CMS. History, rollback, and review come for free, and there’s no second source of truth to drift out of sync with the first.

    Type and texture

    The design is a bespoke paper theme: warm paper in light mode, charcoal in dark, both driven by the same HSL CSS variables so they stay one system instead of two coats of paint. Four typefaces carry it — Archivo Black for display, Inter for body text, Instrument Serif for italic accents, and JetBrains Mono for metadata — and structure comes from hairline rules rather than boxes. There are a few Framer Motion touches around the site, and all of them respect prefers-reduced-motion. This page uses none of them; it’s plain HTML, readable anywhere.

    How AI fit in

    I built this site in collaboration with Claude, Anthropic’s AI, working through Claude Code over a handful of sessions. The division of labor was the one I argue for everywhere else: I owned the judgment calls — what to build, what to cut, how it should feel — and Claude did the heavy implementation, with every change verified in a real browser before it shipped. The speed was real. So was the review. Nothing landed on trust.

    I’ve written that AI is an amplifier for good product judgment, not a replacement for it. This site is the closest thing I have to a worked example. The parts a model could do fast, it did. The parts that made the site worth building — the positioning, the taste, the decision to keep it boring — were mine, and they were never up for delegation.

    The point

    None of the choices above are clever, and that’s deliberate. Static files, git as the source of truth, build-time work instead of runtime servers: boring foundations compound. The site costs almost nothing to run, asks almost nothing of me to keep alive, and every future feature starts from a simpler place than it otherwise would. My homepage has a section called “How I think.” This site is that section, running in production.

    If any of this is useful, the writing goes deeper — or say hello on LinkedIn.