How We Automated This Entire Blog (And Why)

Here's a confession that probably belongs in the small print: no human wrote this post, and no human pressed publish either. On the first of the month, a computer the size of a deck of cards went looking for what was actually happening in our corner of the industry, wrote ten posts including this one, and dropped them onto a calendar. Weeks later it woke up, decided today was this one's day, pushed the site to the web server, wrote a Facebook caption from scratch, waited a random stretch of the afternoon so the timing looked human, and posted the link.

That's not a fancy platform. It's a $50 Raspberry Pi running about 850 lines of script spread across five files. Since we get asked "wait, how does that work?", here's the whole thing in plain English — including the part most shops would rather not print.

Once a month: the part that writes

At 4am on the first of the month, a cron job wakes the Pi, pulls the latest code, and calculates ten publish dates that continue the existing every-three-days cadence. Then it hands those dates to Claude, running headlessly on the Pi itself, along with a prompt file that tells it to search the web for what's genuinely trending this month, pick ten topics that don't duplicate anything already on the blog, and write them. The prompt's own words: "Work autonomously and finish the whole job... Do not ask questions." When it's done it renders a social card for each post, adds them to the manifest, commits and pushes.

There is no approval queue. The checks that run after the batch are purely mechanical: if a finished post has no publish date, or is dated more than 180 days out, the run fails a healthcheck and pings us. That guard exists because the drip once went dark for 40 days while 21 finished posts sat eight months in the future. Nothing in the pipeline reads the prose.

Every morning: the part that publishes

At 9:20 every day, the second cron job does five small things in order:

• Pulls. Fast-forward only, so a bad local state can never clobber the repo.
• Decides what's live. A post appears only when both are true: its date has arrived and its HTML file actually exists on disk. The index, sitemap and RSS feed are regenerated from that answer every run.
• Waits. If something goes live today, it sleeps a random interval of up to about eight hours before deploying, so the every-three-days reveal lands at a different, human-looking hour each cycle. On days with nothing new, no wait.
• Ships everything. One SFTP connection uploads every file that is currently live — 56 entries today: sitemap, robots, stylesheet, blog index, feed, every published post, every social card, plus the main site pages. Not just the new one.
• Tells people. If a post went live today and the Facebook credentials are present, it asks Claude for a caption, picking one of seven "vibes" at random so they don't all read the same, waits another random stretch of up to forty minutes, and posts the link.

The full redeploy looks wasteful until you know our host's firewall blocks the IP after roughly five connections in an hour — one connection that pushes everything is safer than several targeted ones. The caption has a guardrail too: if Claude is unreachable, or returns something empty, too long, or containing a URL, it falls back to a plain "New on the blog:" plus the title. And every run checks how long it's been since anything actually published; more than seven days and it trips an alert, because that 40-day outage happened while this script exited cleanly every single morning.

So what stops it being slop?

Not a person reading it first. That's the honest answer, and we'd rather say it than imply an editor who doesn't exist. What is there is a stack of constraints the writer has to satisfy before a post counts as valid at all:

• A written post contract. A spec in the repo listing every required element in order: the answer-first summary box, the skimmable headings, the pull-quote, the "where people go wrong" box, the four-question FAQ, the call to action.
• A gold-standard reference post. One existing article the batch is told to open and copy structurally, so ten posts written in one run don't drift into ten different shapes.
• Topic guardrails. Read the whole manifest first and don't repeat a topic. Stay in the six subject areas the blog covers. Tie each post to something real and current. Never fabricate statistics, benchmarks, client names or testimonials. And only link to a post whose file already exists — a rule added after the archive quietly accumulated about fifty dead internal links.
• Structural validation. Every post carries three blocks of structured data, and its FAQ schema has to match the visible questions word for word. A post that doesn't build correctly never gets published.

The interesting question was never whether a machine wrote it. It's what the machine had to satisfy before it was allowed to publish.

That's a real quality floor, and it is still not the same thing as an editor. If a post is thin, or the writing is flat, nothing here catches it. We'd rather say so than pretend, because it's exactly the conversation we have with clients: automation is only ever as good as the constraints and the checks you wrap around it.

Why bother? Isn't this overkill?

For one blog, maybe. But the same pattern — "do the repetitive thing on a schedule, reliably, without a human" — is worth real money in a business. Sending invoices. Syncing inventory. Emailing the weekly report. Backing up the database. These are the quiet tasks that eat hours and, worse, get forgotten on the busy weeks.

We automated our own blog because it's the cheapest possible demonstration of the whole pattern. Every piece is something a real business needs: work that happens on schedule without anyone remembering, a deploy that can't take the site down, credentials that live on one machine and never in the repo, and an alarm that shouts when the thing quietly stops working.

Where people get automation wrong

If your team has a "someone has to remember to do this every week" task, that's usually the first thing worth handing to a script. Curious what that looks like? It's the same muscle we use to build AI agents and the custom software we ship for clients.

Frequently asked questions