How This Blog Works (or: More Infrastructure Than Posts)

Jekyll, WordPress, a static site, Strapi, and now Obsidian plus Nuxt. Years of rebuilding a blog that had almost no posts, and how the current setup works.
On this page
A short history of rebuilding instead of writingWriting happens in ObsidianPublishing is a buttonThe site itselfWas it worth it?CommentsIn my first post I admitted I'd spent more time building this blog than writing on it. I'd love to tell you that changed.
The first commit in this repository is from October 2019. The first post went out in May 2025. Since then the site has gained 45 Vue components, 19 test files with 174 tests, and a publishing pipeline with its own GitHub workflow.
Number of posts before this one: two.
So, since I clearly enjoy the plumbing more than the writing, let me at least show you the plumbing. And where it came from, because this repository is only the latest chapter.
A short history of rebuilding instead of writing
This blog has been a work in progress for much longer than 2019.
It started on Jekyll, because that's what developers did: Markdown files, a static site, free hosting, and a theme I spent more time customising than writing for.
Then I moved to WordPress, because surely the problem was the tooling, and a real CMS would finally make me write. It made me install plugins.
Then back to a plain static site, because WordPress felt like a lot of server for a very small number of posts.
Then Strapi, a headless CMS with a separate frontend, because a static site obviously needed an API, an admin panel and a database behind it.
And now: notes in Obsidian, posts in Git, Nuxt in front. Along the way the blog also moved from a subdomain to the main domain, which is the web equivalent of finally putting your name on the door.
Five platforms, one post. If there's a lesson, it's that the tooling was never the reason I wasn't writing. I still enjoyed every migration, which tells you a lot about my job.
Writing happens in Obsidian
All my notes live in Obsidian, and so do my drafts. There's a Writing folder, and every post starts there as an ordinary note, next to ideas, half-finished thoughts and at least one draft that's been "almost done" for far too long.
When a post is ready, I mark it in the note's front matter:
published: true
That's the whole decision. Everything after it is plumbing.
Publishing is a button
My vault is synced to a private Git repository. The site lives in another repository, and the two never mix: the vault is never part of the site build.
To publish, I press a button. Specifically, I run a manual GitHub workflow called "Publish from the vault". It:
- checks out only the Writing folder and the attachments of the vault, with a read-only key,
- converts the notes marked
published: trueinto posts for the site, - opens or updates a pull request with the result.
Then I review that pull request like any other change: read the diff, check the preview, merge. A post goes live the way code goes live, through review.
And there's no AI anywhere in that path. Plain scripts, on purpose. I like knowing exactly what happens between my note and your screen. Given what else I write on this blog, I'll let you enjoy that irony on your own.
The site itself
The site is built with Nuxt and Nuxt Content: the posts are Markdown files in Git, rendered on the server. The repository has type checks and a test suite I run before merging anything.
174 tests. For a blog. I know. In my defence, they caught real bugs, and in the defence of anyone reviewing my career choices, none of them caught the bug where I don't write posts.
Was it worth it?
As a blog, probably not. Any of the five platforms would have let me write in an afternoon.
As a playground, absolutely. I learned a lot about Nuxt, rendering on the server and publishing pipelines by building this, on a project where breaking things only embarrassed me.
And it does feel good to write a note in Obsidian, press one button, review a pull request and see it appear here. It just took me five platforms to start.
Next post: hopefully less than six years from now. Assuming I stop tweaking the blog.
Software Archaeology: Modernising Code Older Than Me
When you modernise a system older than you are, everyone's first instinct is to open the code. Mine isn't. How I dig a business out of its data and its people instead, and why the code is the last place I look.
10 Feb · 5 min How to Build Software That's Doomed to Fail, in 6 Easy Steps
A practical guide for anyone who wants their next big software project to end in a cancelled go-live, written from years of watching the method work perfectly.


Comments use GitHub Discussions through Giscus. Nothing loads until you ask for it.