Motivation Is a Terrible Content Strategy
I used to treat content like a mood.
If I felt inspired, I'd write. If I had a packed day, I'd skip. If ad fires popped up, blog was dead for a week.
That works if content is a hobby. It doesn't work if content is an acquisition channel.
So I stopped pretending I was going to "be more disciplined" and did what I always do when a repeated task annoys me: I told Ari to automate it.
Now every morning at 10am, one article gets produced and published from a pre-built queue.
No hype. No "batch day" theater. No waiting for a creative window.
Just output.
The Core Rule: Queue First, Writing Second
The pipeline only works because the queue is decided ahead of time.
I had Ari build projects/machine-earned/blog/article-queue.md as the source of truth for the month:
- 30 article titles
- category/tag mix
- a clear one-line brief per post
- source material notes for technical/factual posts
- publish tracking via
[PUBLISHED]
That one file solves 80% of the usual content chaos.
Most teams get stuck because they ask "what should we write today?" every day. That's a strategic question pretending to be an operational one.
We answer strategy once, then execute daily.
What Actually Runs at 10am
Here's the real flow:
- Read the queue and find the next unpublished article
- Pull source context (scripts, docs, prior notes)
- Draft the article in my voice (first person, founder perspective)
- Generate a hero image with KIE
nano-banana-2(16:9, dark/tech) - Build the static article HTML
- Rebuild blog index
- Deploy to the server
- Mark that queue item as
[PUBLISHED]
The important part is this is one deterministic run, not a dozen manual mini-tasks.
Why This Is Better Than "AI, Write Me a Blog Post"
Most AI content setups fail for one of three reasons:
- No constraints (generic slop)
- No source files (hallucinated details)
- No deployment path (drafts sitting in docs forever)
I designed around those failures.
1) Constraint: Voice + rules are explicit
I force a specific voice: me as founder/operator.
Not "an AI assistant sharing tips."
Not "a neutral editorial voice."
Not fake thought-leadership fluff.
The framing is real: I decide, Ari executes, we ship, we review outcomes.
2) Source-grounded writing
When an article references systems, scripts, or results, Ari has to read the actual files first.
That keeps posts tied to reality:
- real script names
- real process constraints
- real mistakes
- real decisions
The quality jump from this alone is massive.
3) Built-in publish step
If the article isn't live, it's not done.
I had Ari wire the builder/deployer script (scripts/publish_me_article.py) so the same run that writes the article also compiles and deploys it. No handoff. No "I'll publish later." No orphan drafts.
The Build/Deploy Layer (Simple on Purpose)
I didn't want a heavyweight CMS workflow for this site.
The Machine Earned blog is a lightweight static publishing flow:
- each article lives in its own folder (
article.md,hero.jpg) - markdown + frontmatter are parsed into HTML
- index page is regenerated from all article metadata
- assets are copied into article build folders
- deployment pushes files to the VPS via SFTP
Could I overengineer this with a full content backend, editorial UI, webhooks, preview environments, etc.? Sure.
But that's not the game right now.
The game is publishing useful content every day with near-zero friction.
The Image Step Matters More Than People Think
Most auto-generated blog workflows either:
- skip images entirely, or
- use random stock-looking garbage that tanks perceived quality
I wanted consistency without turning image creation into a design project.
So I standardized hero generation with one command against KIE nano-banana-2:
- 16:9 aspect ratio
- dark/tech visual language
- no text in image
- output directly to the article folder as
hero.jpg
This gives every post a coherent visual identity without me touching Figma.
The Hidden Win: Reduced Decision Fatigue
People talk about automation like it's only a speed thing.
For me, the bigger win is cognitive load.
When content is manual, you burn energy on low-value decisions:
- What topic today?
- Is this good enough?
- Should I post now or later?
- Do I need an image?
- Did I update the index?
Multiply that by 30 days and it's a tax on execution.
The 10am system removes all those micro-decisions.
I front-load the thinking into the queue, then let the machine run.
Where Humans Still Matter
I'm not pretending this is "set and forget forever."
I still review outcomes and adjust the system:
- Which posts get indexed fastest
- Which titles pull clicks
- Which topics drive qualified traffic
- Which voice patterns feel strongest
Automation handles repetition.
Direction still comes from me.
That's the right split right now.
What Broke While Building It
A few practical lessons from implementation:
- On this Windows setup, Python path consistency matters. We use the full Python 3.12 path every time to avoid shell alias garbage.
- Complex one-liners in PowerShell are fragile. Writing small Python scripts is more reliable.
- Publishing state tracking in one queue file prevents duplicate posts and missed days.
- If you don't enforce source material checks, AI will confidently invent details.
None of this is glamorous. All of it is the difference between a demo and a working pipeline.
If You Want to Copy This
Steal this structure:
- Create a 30-day queue in markdown
- Add a one-line brief and source notes for each entry
- Enforce one voice/persona
- Build a deterministic publish script
- Make publishing state explicit (
[PUBLISHED]) - Run daily on a fixed schedule
You can do this for:
- founder blogs
- SaaS SEO pages
- niche media sites
- agency content engines
The specific tools don't matter as much as the operating model.
Why 10am?
Because consistency beats cleverness.
10am is late enough that overnight infra issues are usually obvious, and early enough that content is live during the business day.
Mostly though, it's just a fixed anchor.
Once the system has a stable trigger time, the rest of the workflow becomes predictable. Predictable systems compound.
Final Take
I don't want to "work on content" every day.
I want the business to have content every day.
Those are different goals.
The first depends on my mood.
The second depends on systems.
So I had Ari build the system.
And now, at 10am, it ships.
---
I’m building systems that let one operator do the work of a small team. If you want the behind-the-scenes playbook as we ship in public, follow along at machineearned.com.