Building a blog I'd actually keep upproject

I’ve started personal sites before. I’ve also let all of them rot. The pattern was always the same: I’d nerd out on standing up the actual database, a CMS, and a server (the parts that came easy to me), write three posts, then watch it pile up updates to install and backups to babysit until logging in felt like a chore, and the chore always won. The site I wanted didn’t need to be clever. It needed to be low-friction enough that I’d actually keep writing about what I build: AI experiments, and the homelab that runs my family’s digital life.

So this one is deliberately boring. The entire site is a folder of markdown files in a git repository; when I push, Cloudflare Pages runs the build (an Astro project that turns markdown into pages) and deploys it to their edge in under a minute. Writing a post is writing a text file; publishing it is git push. Nothing runs between posts, so nothing breaks between posts. And the static approach buys the things I care about more than features: every change is a diff I can read, everything is reversible because everything is files, and the result is fast and effectively free, plain HTML served from a cache near the reader.

The stack was only half the friction, however. The other half is the blank page, and here I’ll show my cards: every post on this site starts life as an AI draft. Before you close the tab: the draft is never what ships. I edit everything, and more to the point, the model writes against a specification I built first. In a file called voice.md, I distilled years of my own writing (school essays, work documents, the occasional social media post; this blog is intended to be informal, after all), and it pins down how I open, how I close, the moves I overuse, and a hard list of words and punctuation that should never get through (em dashes, for one, against which I hold an irrational and non-negotiable grudge). Every time my edits catch a draft sounding like a machine instead of me, the correction gets folded back into the spec’s changelog. The drafts have been converging on my voice ever since; my red pen is training the ghostwriter.

You’ll also notice I will rarely name the model in my posts, and that’s deliberate. I keep paid subscriptions to multiple frontier AI labs and move between them constantly, chasing whichever is best at the task in front of me. So when a post says “an AI model,” it’s meant to accurately reflect that churn, not be coy about a favorite. Where a specific model is the point of a post, I’ll name it explicitly.

The one part of the site itself I fussed over is the diagrams, which have long served me well in my professional life as a PM. Most posts carry a systems diagram (some make their case better with a screenshot or a photo of the real thing), and the diagrams all share the same hand-drawn style, as though I sketched them on a whiteboard: wobbly lines, marker-weight strokes, a handwriting font. They look casual, but they’re generated from code, in a diagramming language called D2 with sketch mode on. The hand-drawn look signals a simplification rather than a spec: the shape of a system, not the blueprint. And because the diagram is text, when a system changes, I edit two lines and re-render instead of redrawing.

The rest of the design tries to disappear. Off-white background, near-black text, a single accent color, a monospace wordmark, and a lot of whitespace (a longstanding point of contention between me and my design friends; they usually win). The writing and the diagrams are the content; everything else should get out of their way.

One thing I won’t apologize for: this blog is nerdy, on purpose. I’m first and foremost a builder. I didn’t choose technology as a career and grow into liking it; I was taking things apart at my parents’ kitchen table from before my age carried two digits, and the career followed the itch. What’s here is the stuff I’d be building on weekends anyway, written down. If that’s your frequency, you’re in the right place.

The plumbing is boring so the maintenance never becomes the project, and the drafting is shared so the blank page never becomes the excuse. What’s left between me and a published post is deciding whether a project is worth writing about. As for voice.md, I expect it to outlive the blog: a file that teaches a model to draft a post in my voice can teach one to draft an email in my voice. That’s a later project, and the spec is already packed.

I’m glad you’re here.