9-to-5ProjectsYapping
← Back to projects

Work  ·  2026

Building a content pipeline that scales infinitely

Building a content pipeline that scales infinitely

Overview

Our marketing team had shrunk to two people, and content marketing kept losing to more immediate priorities. I built an automated pipeline that researches industry topics, drafts blog posts, LinkedIn posts, and a newsletter, and lets anyone on the team decide what gets written. Output went from a handful of blog posts a month to as much as there are good topics to cover, and the team now spends under an hour a week from research to publication.

< 1 hr/week

Team time reviewing topics and editing drafts

Unlimited

Content volume, capped by good topics not headcount

The challenge

A two-person marketing team can't run a full content function on the side.

Two. That's how many people were left on our marketing team after a year of headcount cuts, and content marketing was the first function to get pushed aside. Someone still had to research industry news, write it up, edit it for brand voice, and publish it, every week, on top of everything else two people were already carrying. Most weeks, that didn't happen.

The need for it didn't shrink along with the team. We still had to build brand awareness and show up as a credible voice in the industry. Falling behind on content doesn't announce itself the way a broken feature does. It just means less gets said, week after week, until there's nothing left to point to.

I built this because two people can't add a whole content function on top of our existing jobs.

The approach

Automate the labor, and put the judgment in more than one person's hands.

The bet was that removing the labor wasn't enough on its own. A few more things had to be true for this to actually work.

  1. The system had to run somewhere that isn't my laptop, so I'm never the reason it doesn't run.
  2. Every researched topic needed to be visible to the whole team, not just to me.
  3. Deciding what to write about couldn't sit with one person. Anyone on the team should be able to say "write this one."
  4. A draft still needed a real set of human eyes before it went anywhere near a reader.

What I did

The whole pipeline runs in the cloud, so nothing waits on me.

Tech stack

Every piece of this had to scale with however many good topics showed up in a week, not with anyone's calendar, so nothing here runs on a machine that has to be turned on.

  • Trigger.dev for the scheduled and event-triggered jobs.
  • A small webhook server on Railway that bridges Slack clicks back into the pipeline.
  • Claude Agent SDK for the research and writer agents, running inside the Trigger.dev jobs themselves.
  • Slack for reviewing topics and approving what gets written.
  • Google Sheets for the topic tracker, Google Docs for every finished draft.

The research loop

A scheduled job runs every Monday morning. It reads a company-context doc, researches the industry, checks new topics against what's already been covered, and scores each one. It posts three to six topics straight to Slack: a brief, the angle, the key facts, and checkboxes for which formats to write. It just runs, no reminder needed.

Why it runs as a remote agent, not on my laptop

I could have built this as a script I run myself. I didn't, on purpose. If it lived on my machine, I'd be the bottleneck: it only runs when I remember to run it, and it stops the moment I'm out sick or buried in something else.

Running it as a remote agent also means the whole team sees what's been researched, not just me. Every topic lands in Slack, so anyone can react to industry news whether or not they're the one who ends up writing about it. That visibility changes who gets to decide what we publish. It stopped being one person's backlog. Anyone can check a box and say "write this one," and anyone can weigh in on a draft before it ships.

The draft-to-publish loop

Once someone approves a topic, a writer agent drafts it, a second agent edits it for brand voice, and the finished piece lands as a Google Doc with a link posted back to Slack. Every format runs through the same review step: a human reads it, edits it, and only then does it go out.

The results

Content output stopped being capped by who had time and started being capped by good ideas.

Before this, we were lucky to get a handful of blog posts out in a month, and LinkedIn and the newsletter got whatever attention was left over, which was usually none. Now the constraint isn't time, it's topics. We publish a blog post, a LinkedIn post, and a newsletter for every genuinely interesting angle the research turns up. A week with six worthwhile topics gets six weeks' worth of content instead of one.

The team's time investment on the whole function dropped to under an hour a week: reading the researched topics, checking the boxes for what we want written, and editing the drafts that come back. Everything upstream of that step, the research, the draft, the brand-voice pass, happens without either of us touching it.

The bigger shift is who gets to decide. Content used to be whatever one person had time to think about. Now it's a standing decision the whole team makes together, drawn from a real research pipeline instead of whoever happened to catch the news that week.