The problem with “you need a CMS”
Every time I wanted to publish something, the conventional answer was the same: install a CMS. WordPress, Ghost, Webflow, they’re good tools, and they exist for a good reason. They let people who don’t write code update a page without breaking the layout.
But I write code. And I’m the only person editing this site. So I was being sold a database, a PHP runtime, a plugin ecosystem to babysit, and a login page to defend, so I could do something a text editor already does.
The convenience I actually wanted was small: write in one place, hit publish, watch it go live. The stack people sell you for that is enormous.
The realisation: git is the database
A blog post is just text with a little metadata. A title, a date, a category, a teaser, a cover image. That’s a row in a table.
So I stopped reaching for a table. Every post is one file, and the metadata lives in that file’s head, right next to the content it describes. No schema, no migrations, no ORM, no connection pool. There’s a file, and it says what it is.
The query is the build. A small script reads every post, sorts them, and generates the Journal index. Ordering, categories, the whole listing, all computed when the site is built, not when a visitor arrives. Which means nobody’s browser ever waits on a database, because there isn’t one.
How it actually works
The whole pipeline, start to finish:
1) I write in Mission Control, my own desktop dashboard, the back office of the studio. The blog composer lives inside it.
2) When I hit publish, a small local service takes over. It writes the post file, rebuilds the Journal, and makes a commit.
3) That commit is pushed to the repository. The host sees the push and rebuilds the site, compiling the CSS, running the generator, shipping the result.
4) You get a plain HTML page. No server-side rendering, no cache misses, no database.
The only thing that runs is the build, and it runs long before anyone shows up.
Staging, going live, and deleting
I keep two branches. dev is where posts land first, and the host ignores it, it’s my sandbox. main is what’s actually live. Going live is one push: dev to main, and the site rebuilds.
Deleting is just as small. A live post is a file. Removing it is a commit. My dashboard has a delete button; underneath, it deletes the file and lets the build regenerate the index.
Which means every change is reversible and traceable. I can see the exact history of every post I’ve ever written, when it changed, and why.
The honest trade-offs
This isn’t magic, and it isn’t for everyone.
There are no live queries. Search, filtering, “related posts”, all of it is decided at build time. That’s perfect for a blog and completely wrong for an app with user accounts and dashboards.
Deletes aren’t really gone. Removing a post takes it off the site, but it stays in git history, recoverable forever. Usually a feature. Worth knowing if it isn’t.
It’s solo-shaped. One writer, one workflow. The moment you have multiple editors, roles, and a publishing schedule, you’re describing a CMS, and you should probably use one.
But if you’re one person who writes code and just wants to ship words? You already own the database. It’s git.
Why I’d do it again
The site is fast because there’s nothing in the way. There’s nothing to hack at runtime because nothing runs at runtime. There’s no rent, no plugin to patch, no vendor to depend on.
But the best part isn’t the speed. It’s that the entire workflow is mine, from the editor I write in to the button that ships it. Nothing in the chain is rented, and nothing is locked in. It’s just files, and they’ll open in twenty years.
So when people ask which CMS I use, the honest answer is: none. I use git, a build step, and a dashboard I built myself. Turns out I already had everything I needed.
