How I Built a One-Minute Blog Publishing Pipeline

I used to treat "publish a blog post" as a half-day chore, so I mostly didn't. Now I describe a lesson in plain English and it's live in about a minute. Same me, same hours, just a lot more output. Here's exactly how the system works, and the three things that tripped me up so you can skip them.

The real problem wasn't writing. It was friction

I never had a "writing" problem. I had a friction problem. Every post meant opening an editor, hand-formatting HTML, remembering the meta tags, copying the JSON-LD, updating the index page, editing the sitemap, then manually uploading files somewhere and praying nothing broke. Each one of those steps is small. Stacked together, they're enough to make you quietly decide "I'll post next week" forever.

For a solo operator, that's the whole game. The bottleneck is rarely ideas or even time to write. It's the tax on every publish. Lower that tax to near zero and the same person ships five times as much without working more. That's the multiplier I'm always chasing: not "work harder," but "make the next unit of output cost almost nothing."

So I rebuilt the pipeline once so that publishing would cost me a sentence instead of an afternoon.

The stack, in plain English

Three pieces, and only one of them is interesting:

• A static site on GitHub. Plain HTML: no database, no build step, nothing to break. The whole site lives in one repo.
• Netlify on continuous deploy. Netlify watches the repo. Every time a change is pushed, it redeploys the live site automatically. I don't touch a dashboard or upload a file. Pushing is publishing.
• A reusable Claude Code skill. This is the part that does the heavy lifting. A Claude Skill is just a folder of instructions that teaches the AI how to do a specific job my way. Mine knows the brand name, the voice, the color tokens, the exact SEO checklist, and where every file lives.

The skill is what turns "write a blog post" from a vague request into a consistent, repeatable output. Without it, I'd be re-explaining my brand and SEO rules every single time, which is exactly the re-pasting tax that skills are built to kill. If you want a sense of which other repetitive jobs are worth packaging this way, I broke down my top five in 5 Custom Claude Skills Every Solopreneur Should Build.

The workflow now

Here's the actual sequence, start to finish:

1. I describe a lesson to Claude Code in plain English, roughly the same way I'd explain it to a friend.
2. The skill writes the full post: headline, TL;DR box, sections, internal links, and every SEO element (title, meta description, canonical, Open Graph, and the Article + Breadcrumb structured data).
3. It updates the blog index.html with a new card and adds the URL to sitemap.xml.
4. It commits the change and pushes to GitHub.
5. Netlify sees the push and deploys. About a minute later, the post is live.

That's it. I review before the push (I always glance at the files), but the work I personally do dropped from "a half-day of formatting and uploading" to "describe it, read it, approve it." The post you're reading right now went through exactly that pipeline.

The goal of a good system isn't to remove the human. It's to remove everything that isn't the human's judgment.

What tripped me up (the useful part)

If this were frictionless to set up, everyone would already have it. It wasn't. Three snags cost me real time. Here they are so they cost you none.

1. The GitHub token kept throwing a 403

I created a fine-grained personal access token, scoped it to the one repo, and pushes still failed with a 403. The repo was selected (that part felt obvious), but selecting the repository alone isn't enough. Fine-grained tokens need you to grant specific permissions on top of repo access. The fix was turning on "Contents: Read and write" explicitly. The moment I added that permission, the push went through. If you're staring at a 403 with the right repo selected, this is almost certainly it.

2. Dragging a folder into GitHub nested everything one level deep

When I first loaded the site into GitHub, I dragged the whole folder in. GitHub kept the folder, so instead of index.html at the repo root, I had everything one level down inside a subfolder. Netlify deployed... nothing useful, because it was looking at the root and the site lived in the subfolder. The first deploy was a blank shell.

My first instinct was to leave the files where they were and just point Netlify's publish directory at the subfolder. That worked, until it didn't. The setting was brittle: it lived only in the Netlify dashboard, nothing in the repo reflected it, and the moment the folder layout changed, deploys failed with "deploy directory does not exist." The durable fix was the opposite move: flatten the site to the repo root so index.html sits at the top level, then leave Netlify's publish directory blank so it just publishes the root. Now the repo's structure is the config. There's no hidden dashboard setting to drift out of sync, and every push deploys cleanly. Lesson: when a deploy comes up empty, check where the host is looking, and prefer the fix that lives in the repo over one buried in a dashboard.

3. Keeping it walled off from my day-job accounts

I deliberately didn't want this tied to my usual logins. That meant a separate GitHub account for the business and a repo-scoped token rather than my personal credentials. It's a small bit of upfront discipline, but it keeps the business's publishing infrastructure cleanly separated from everything else: no tangled permissions, no "which account am I in" mistakes later.

Why this matters for a solo operator

The reason I keep coming back to "multiply output, not headcount" is that systems like this are the clearest example of it. I didn't hire anyone. I didn't add hours. I spent one afternoon removing friction, and now a recurring task that used to get skipped now happens in five minutes whenever I have something to say.

That's the compounding part. A post that takes a half-day gets written maybe once a month. A post that takes five minutes gets written whenever a real lesson shows up, which, if you're actually building, is constantly. Over a year, that's the difference between a stale blog and a library of content that quietly does your marketing while you work on something else.

None of this required exotic tooling. A free static host, a Git repo, and an AI that knows your rules. The same logic applies to most of what a small business does by hand: invoicing, follow-up, customer replies, scheduling. If you're weighing AI tools for that kind of work, my honest Claude vs ChatGPT comparison is a good starting point for picking the engine before you build the system around it.

The takeaway

Set the system up once, and "publishing content" stops being a chore you avoid. It becomes a habit that costs you a sentence and a glance. The tech is boring on purpose: static files, a webhook deploy, a skill that remembers the rules. The result isn't boring at all: more output, same hours, no extra headcount. That's the whole point.