The problem
The person writing the posts had no interest in learning a CMS, and shouldn't have to. Webflow's editor is a designer's tool. That left two bad options: the writer learns Webflow, or a developer sits in the loop for every post and every typo fix. And someone still had to pick a cover photo each time without repeating last week's.
What I built
One Google Doc as the writing desk, with a three-item menu: Publish, Open Blog Picker, New. Behind Publish, an automation reads the Doc, checks the header, picks a cover, finds the post by its ID, creates or updates it in Webflow, and writes the ID back into the Doc so the next Publish updates the same post. Pull runs the other way: a live post comes back into the Doc.
What changed
Ten posts published by the owner's team without me in the room, as of September 2026. Nobody logs into Webflow to write. It costs nothing beyond the services the brand already paid for, and it was handed off as a package: a manual for a reader who has never seen it, a writer's guide, and an administrator's runbook.
What the writer sees
Everything happens in one Doc. The header is the block between two fence lines: Title and Pillar are the writer's; Post ID and Slug belong to the system and get left alone. The body is written normally, and headings, bold, links, lists, and quotes carry over as they are. Anything under a NOTES line stays in the Doc and never publishes. The mockup below is drawn in this site's palette; the real thing is a plain Google Doc.
Left: the Doc, its menu, the header block, the Blog Picker sidebar. Right: the post as it lands on the site, cover photo included. Publish goes right; Pull comes back.
How a post goes live, from the writer's chair
- Open the Doc. New post: Point 4 → New / Clear Doc. Existing post: Point 4 → Open Blog Picker, choose it, click Pull. The Doc's contents are replaced by that post.
- Fill the header. Title, Pillar (one of Mindset, Health, Finance, Business), and an optional Subtitle. Leave Post ID and Slug alone.
- Write the post under the header. Headings, bold, italics, links, lists, and quotes all carry over as they are.
- Point 4 → Publish. The post is live at its own address in about a minute. On a brand-new post the Doc gets a Post ID stamped into its header; that line is what makes the next Publish update the same post instead of creating a second one, so it stays.
The mechanism
One automation does all of it, sitting between the Doc and the site. The Doc's menu sends it a single message: this Doc's id, or this post's id. Everything else is the workflow's problem, and the writer never sees any of it.
Publish and Pull are the same road in two directions. Beehiiv, where the signup forms and the newsletter live, sits beside the site today. The next step, already designed and written up in the manual, wires the blog to the newsletter so a published post becomes a send.
Two rules the writer never has to think about
- Post ID is the post's identity. Blank means "new post"; the publisher fills it in, and Pull fills it in too. A Doc with a Post ID always updates the post it names. Clear it by mistake and you get a second copy; the manual says exactly how to fix that.
- Slug is fixed the first time. The last part of the address is made from the Title at the first Publish and then never changes. The Title can change later without moving the URL, so nothing anyone shared goes dead.
How the cover photo picks itself
Each pillar has a Drive folder of cover photos. On every Publish the workflow rescans that folder and adds anything new to a bookkeeping sheet, one row per photo with a used-on stamp. Then it picks the photo that has gone longest without being used: never-used first, then the oldest stamp, with a random tiebreak. Every photo in the pillar gets used before any repeats. After the post is written it stamps that row and saves the Webflow asset id, so the same photo picked again later reuses the same upload instead of making a copy.
To add covers, drop files in the folder. To force a specific one, put the image in the Doc; an image in the body always wins. To push a photo to the front of the line, clear its stamp. That is the whole photo workflow, and none of it involves opening Webflow either.
How it stays alive after I leave
The publisher is one n8n workflow, exported to a file that imports anywhere. The Doc's menu is one script, pasted once. The manual is written for a reader who has never seen the system: the five pieces, how a post goes live, how photos rotate, where everything lives and who holds the keys, a one-line health check to run from any terminal, and a symptom table for when it fails. The writer's guide and the administrator's runbook are separate documents, because those are two different people.
Two notes, because they are in the manual too. The workflow runs as a guest on an automation server that belongs to another company, by agreement, and the manual says who to call. And the newsletter leg is next: today Beehiiv runs the signup forms and the sends alongside the site, and the design for feeding it from the blog, so a published post becomes a newsletter, is written up and waiting. Writing the next step down is part of a handoff; the person after me starts from a plan instead of a mystery.
Stack
The same shape as the photos-to-web pipeline: one automation in the middle, plain services on either side, and a manual that assumes the reader has never met the system.
Built in conversation
Same method as everything on this site. The workflow's twenty-eight nodes, the Doc's menu script, and the three manuals were designed and written in dialogue with Claude. The hard part wasn't wiring an API. It was deciding what the writer should never have to see: no ids, no settings, no second copy of a post. Those are design conversations, and I had them with a machine that asks the follow-up question every time.