My blogging workflow: from idea to production

I started writing a long time ago, even before this website was built. At the time I was maintaining a Squarespace website, because I thought it would be a good idea. My oversight was that I’d be paying for a subscription for the rest of my life if I wanted to keep the blog alive.

When I realised the deep hole I was in, I dug out and started this blog. A codebase of my own that I can easily tweak and maintain. Plus, now I have a way to automate parts of it.

Step 1: Saving the ideas

On my day to day, ideas on what to write about jump to me. Sometimes I’m eating lunch, other times I’m about to fall asleep, or I’m doing the dishes. Most often than not, it happens when my hands are busy and my mind can wander.

At this point, what I usually do is rely on Todoist Ramble to just speak out loud to my phone and keep these ideas somewhere safe. Ramble lets me add a few tasks just by talking, while my hands are busy.

Later, when I get to a computer, I migrate these ideas to my Obsidian vault. This is a folder stored on my NAS, synced with Syncthing between my devices.

The folder is broken down into three subfolders:

• Ideas — where I dump the ideas
• Started — posts I’ve started but haven’t finished yet
• Live — a repository of all the posts that are live

Each folder has markdown files. Each post is represented by a markdown file, just like it is in production—more on that later. Whenever I start writing a post, I drag the respective file into the Started folder.

Step 2: Dumping my brain into a file

At this point the post is nothing but an empty markdown file with a name. The first thing I do is expand an Obsidian template into this file, which contains the front matter that my website needs to read.

Then, I make a small list of 3 to 6 sections I want to cover in the post, and go through them one by one, expanding each with thoughts. This is almost literally brain dumping—I don’t care about formatting, typos, missing uppercase characters, etc. I just dump ideas into the file.

I can do it this way because the next step involves AI. Before AI, I would be way more careful with formatting, which would make me spend way more time in early phases.

After this step, the post is written, but one thing is for sure—the formatting, typo checking and all that still needs to be taken care of for production.

This is where AI comes in.

3: Making it pretty with AI

A special trick I use is asking the agent to do specific tasks. For instance, if I’m writing about browser metrics, I could spend my time doing the research myself and extracting what matters for me. But I don’t. I leave that for AI. But I don’t do it blindly though, because I don’t trust it that much.

I ask it to go and fetch the metrics, point me to the sources and expand my (AI:) prompts. For instance, I could have this:

Chrome has been gaining more and more users for the past few years (AI: fetch the numbers and place them here).

So I offload the research heavy lifting to AI, but I still look at the sources, make sure what the agent extracted makes sense, and leave the sources in the post.

I copy all the contents from the post file and paste it into either opencode or ChatGPT (depending on which device I’m on), where I already have a blog-writing skill set up with very precise instructions on what to do. I force it to leave my content intact as much as possible, focusing mostly on typos, errors and stuff like that. It’s polishing more than anything.

I may also use it for generating intro texts based on the whole post, suggesting an icon, or a new title. But that all depends on the post itself and whether or not I already have an idea of what I want.

Of course I could also just tell it to “write me a post about browser metrics” and it would—I promise I’m not writing a post about browser metrics. But that kind of defeats the purpose of writing in the first place. I started writing because I enjoy the process, not because I want to own a blog. The blog came to life as a means to share the writing.

After the whole post is done, I copy it back to Obsidian, where I read it top to bottom, making sure I haven’t forgotten anything and the reading flow feels natural.

When everything is ready, it’s time to add it to my website.

4: Adding the new post to my website

My website is built with Eleventy, which also uses markdown files with front matter—just like Obsidian.

Which means I could effectively open Obsidian directly in the posts folder inside my Eleventy website, and every new file added in Obsidian would mean a new post added to my website.

But at this point, I’m separating these on purpose.

To add the post to my website, the easiest and most portable way I found was doing it directly through GitHub itself. I create a new branch, add a new file in the posts folder, give it a name, and make sure the formatting is right. Then I commit the changes and open a pull request.

Opening a pull request generates a preview URL via the Cloudflare Pages integration, which lets me preview the post one last time, directly on my website. If I need to update something, I can just as easily do it through GitHub as well.

Doing it this way makes it consistent for me to add blog posts whether I’m using the desktop, laptop or tablet. Of course I could just checkout the repo on a computer and open the project in Neovim, but I wouldn’t be able to do that on the tablet just as easily. So I’d rather stick to a fully portable workflow.

5: Automating the deployment

The last piece of this puzzle is a very nice addition called Merge Schedule.

Merge Schedule allows me to have a pull request template with the date baked in:

## 📆 Go live date (automatically)

/schedule 2026-05-12T13:00:00.000+01:00

So when I open a pull request, I already have this date format in place. I just need to check the date on which I intend to publish the post and change it here.

This allows me to write and prepare blog posts for production weeks or months in advance, knowing they will sit in the pull request queue and only be merged when the time comes.

The best part is that I don’t need to do anything else at this point. I could be driving, having lunch or on vacation. The blog posts will go live—on their own.

I get an email notification every time some activity happens on the repo, so I always know when posts go live.

Takeaways

That’s the whole chain. A thought pops into my head while I’m washing dishes, I mumble it into my phone, and weeks later a formatted post goes live on its own while I’m on vacation. Every piece of the puzzle exists to remove friction at a specific point: voice capture for when my hands are busy, brain dumping for when I don’t want to think about structure yet, AI for when I’d rather write than proofread, and Merge Schedule so I never have to remember when to publish.

The blog exists because I like writing, not because I like managing a blog.