Rebuilding jesseahawkins.com in the open

The site you’re reading this on is the third attempt at a personal site, and the first one built with the process itself as part of the pitch. Worth explaining why.

What broke

The previous version — JAH.SYS, a terminal-themed personal site — was a client-rendered Next.js app. It looked sharp in a demo and failed at the one thing a personal site actually needs to do: exist reliably when someone looks for it. Three specific failures:

It depended on a backend that could go down, and did. A stateful server behind a personal site is a liability with no corresponding benefit — nobody needs real-time data to read a CV.

It was invisible to search engines. Content that only renders after client-side JavaScript executes is content that doesn’t exist to most crawlers, and doesn’t exist to link previews either. Share the URL in a chat app and you’d get a blank card.

It produced no OpenGraph output, which compounds the second problem. A personal site’s job is partly to travel well — to look right when someone pastes the link somewhere. A site that can’t produce a preview card is failing at distribution before anyone’s even read a word.

None of this is exotic. It’s the standard failure mode of reaching for a framework because it’s interesting to use, rather than because the page actually needs it.

What the rebuild does differently

The rule I’m building against is simple: static-first, edge-rendered, crawlable, degrades gracefully. Concretely:

Content lives in the HTML. If a feature’s output only shows up after JavaScript runs, it doesn’t ship. This isn’t a performance preference, it’s a correctness one — search engines, RSS readers, and link-preview bots don’t run your JavaScript, and pretending otherwise is how the last site failed.

JavaScript is opt-in, per component, not the default. Astro’s island model makes this cheap: a page with no interactivity ships zero framework JS. Most of this site’s pages will stay that way indefinitely.

The site never depends on a server that can go down. Static assets and edge workers only. If a scheduled pipeline fails to update, the site keeps serving the last good version — never a spinner, never an error page, just slightly stale content that’s honestly labeled as such.

Cloudflare Pages builds and deploys directly from a push to main. There’s no separate deploy step to forget, no staging environment to let drift. What’s in the repo is what’s live, on a short delay.

Why build it in the open

“In the open” here means the reasoning is published, not that the repository is. The repo is private; what’s public is the record of decisions — this blog, the project write-ups, and the fact that every page states what it can’t do as plainly as what it can. Commit messages, docs, and the shape of the code are still treated as work product rather than as private scratch, because the discipline is what produces the result, and because I’d rather build as though someone were reading.

That’s a weaker guarantee than a public repo, and it’s worth being precise about which one you’re getting. A reader can check the claims against the site’s own behavior — whether a page really does render with JavaScript off, whether a failed pipeline really does serve labeled stale content instead of an error — and that’s the part I’d actually want checked. The code behind it, I’ll walk through on request.

It also means the build process itself can be part of what the site demonstrates. A daily automation loop reviews the roadmap, picks up the next item, and ships small, verified changes directly to main — the same build-or-revert gate that protects a normal deploy is the only safety net, on purpose. Whether that’s a good idea long-term is still being tested. I’ll write about it as it either holds up or doesn’t.

What’s next

Foundation and a first design pass are live: the shell, home page, CV, and contact page, all static and zero-JS. This post is the first thing in what comes next — a proper blog, then the Wire (a couple of daily machine-written publications), then a set of small interactive agents in the Lab. Each one gets built against the same rule: real data or an honestly labeled absence of it, nothing simulated to look finished.