I have built this exact thing in my career — a place to publish words on the internet — somewhere between ten and twenty times. Drupal sites. WordPress sites. Custom CMSes I hand-rolled from scratch and then had to maintain forever (or until I left and the servers died). Legacy newspaper publishing systems that also fed the print-design pipeline, because the same article had to become both a web page and a physical thing made of ink. Every one of them worked. (Because I am very talented, obviously.) But each was a beast — databases to back up, admin panels to log into, plugins to update, a login screen standing between me and the act of writing.
Every time I did it, I wanted to make it simpler. Not a little, but a lot.
And I think I’ve done it now for the Endgame engineering blog, while also making sure it’s easy to use for my coworkers and looks pretty online.
Here’s what I did:
-
Write in markdown. A post is one
.mdfile. No editor, no database, no admin panel — just text. -
Set one line of metadata. At the top of the file you say whether the post is a
draft(nobody can reach it),unlisted(live but not on the homepage), or published (it shows up for everyone). One word, and you control exactly who sees it. -
Drop in an image if you want one. Point the post at a cover image and it shows up as the header and the homepage thumbnail.
-
Push to GitHub. That’s the publish button.
-
Vercel does the rest. The repo is connected to Vercel, so every push automatically builds the site and deploys it.
-
One CNAME, once. To put it on a real address, I added the subdomain in Vercel and pointed a single CNAME record at it.
-
And the biggest one: I didn’t build most of this. I used Astro for turning the markdown into a static site, Bun runs it locally, and Shiki and MDX take care of some other cruft. All free, all open source. Hand-rolling that would be stupid now.
That’s it. Or an even simpler understanding, for those who like visuals:
Engineers should endeavor to simplify as much as possible. Even with their fun little blogs.