This Post Scheduled Itself

October 28, 2026 - Reading time: 3 minutes

You're reading a post that put itself on the schedule.

I wrote it earlier today as a plain Markdown file, handed it to a small command-line tool, and queued it to publish at 6:00 PM. I didn't log into the admin at 6:00. I didn't push a button. The post simply showed up on time, because that's what I told it to do hours earlier.

That small bit of theater is the whole point, so let me explain what's going on.

The problem: publishing is a chore, so I don't

I like having a blog at tap.keg.dev. I'm less fond of the ceremony around posting to it. Open the admin, paste the text, fix the formatting, upload the images one by one, pick a category, hit publish. None of it is hard. All of it is friction. And friction is where good intentions go to die — the draft that never ships, the idea that stays in a notes app.

Part of what makes social media so easy to post to is how simple and intuitive it is — there's almost no barrier between having a thought and sharing it. I wanted that same low friction for my own blog. The honest reason this tool exists is that I want to post more, so I removed my own excuses. If writing a post is as cheap as saving a text file, I'll write more of them. If publishing is one command, I'll actually hit publish. My goal is to make posting here feel as routine as the development documentation I write every day.

The solution: write a file, run a command

The tool is deliberately small. There's no dashboard, no service to deploy, nothing running in the background. It's a single script, open source on GitHub at kegdev/bludit-ghostwriter-cli. A post is just a Markdown file with a short header:

---
title: This Post Scheduled Itself
tags: meta, automation
category: News
date: 2026-10-28 18:00
status: scheduled
---

You're reading a post that put itself on the schedule.

Everything above the second --- is metadata; everything below is the post. I run one command and it lands on the site through Bludit's API.

Three things make it pleasant to live with:

• Draft by default. Nothing goes public by accident. I get a final look unless I explicitly say otherwise.
• Images just work. I reference a local image in the Markdown and it gets uploaded for me, with the link rewritten to its hosted URL.
• Scheduling. The feature you're reading right now.

Why scheduling is the quiet hero

Writing and publishing almost never want to happen at the same moment. My ideas arrive in bursts — a free evening, a long train ride, the hour after I ship something. But a blog reads best with a steady rhythm, not bursts.

Scheduling bridges the two. I can write three posts on Sunday and let them trickle out across the week, or finish an announcement days early and line it up for launch morning while I sleep. The work happens when I have energy; the publishing happens when readers are around. For a one-person blog I want to feed more consistently, that gap is exactly the thing worth closing.

The inception bit

This post is the test case. I wrote the scheduling feature, then used it to schedule a post about writing the scheduling feature, aimed at the very blog the tool was built to feed. If you're reading this at or after 6:00 PM on its publish date, the loop closed on its own.

It's a small tool doing a small job. But small friction, removed, compounds. The best feature of a blogging workflow is the one that gets me to actually publish — and then quietly does it again tomorrow.

Grab it

The whole thing is open source. If you run a Bludit site and want to publish from the command line, clone it, read the README, and try the bundled examples:

→ github.com/kegdev/bludit-ghostwriter-cli

More to come, on a schedule. :)