Why I Keep Rebuilding My Own Blog

I write software for a living, which means most days I'm solving problems other people define. This site is different; it's the one project where I get to argue with myself about requirements and lose.

The brief I gave myself was simple: no database, no admin panel to log into from my phone at 11pm, no build step. Just text files I can edit directly and a server that knows what to do with them.

Why Flat Files Won

I've stood up enough WordPress installs for other projects to know exactly what I didn't want here. A blog is, structurally, a very simple thing; posts, dates, tags. It doesn't need a database to do that job.

What's Actually Running This

A small PHP script reads whatever's in /posts, parses a lightweight front-matter header plus a handful of markdown-like conventions (headings, code blocks, callouts like this one), and renders it through a shared content system. No framework, no package manager, nothing to keep patched.

function hn_load_post($slug) {
    $path = __DIR__ . '/../posts/' . $slug . '.txt';
    if (!is_file($path)) return null;
    return parse($path);
}

It's a small enough system that I actually understand every part of it, which after years of inheriting other people's stacks is worth more to me than almost any feature.

I'll probably keep tinkering with this; the accessibility panel and the theme system both grew out of "well, while I'm in here." That's most of my dev work, honestly: projects that start scoped and don't stay that way.