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.
Every post on this site really is just a .txt file sitting in a folder on the server. Publishing something new means uploading a file, not clicking through an editor UI.
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.