I Automated My Content Pipeline. Here's the Honest Account.

Subtitle: The build-in-public post I wish existed — including the ratio nobody talks about, and what it means differently depending on your role.

Introduction

I built an AI automation pipeline this week. It reads my Cup of Wit articles from Notion, calls Claude twice for each one, and generates a platform-native LinkedIn post and a YouTube Shorts script — automatically, every morning at 9am.

It works. The path to "it works" looked nothing like the tutorials suggest.

Before I get into what I built and what I learned, I want to address the ratio — because it's the most honest and useful thing I can tell you, and it looks completely different depending on who you are.

The ratio — and why it depends on your role

The day broke down like this for me: 80% debugging, 20% building.

But I need to be precise about what that means — because this ratio is not universal. It depends entirely on where you sit.

If you're a developer or technical builder: This ratio is normal. Expected. The debugging is the work. Every API call, every node connection, every data type mismatch is a lesson in how the system actually behaves versus how the documentation says it behaves. If you're building automation professionally, budget for this ratio and don't treat it as failure.

If you're a business leader commissioning this work: Your ratio looks nothing like mine. You spend 80% of your time deciding and scoping — what to automate, why, what the approval process looks like, what happens when it fails, who owns it after it's built. Then 20% waiting for it to be built. The debugging isn't your problem. The ambiguity is. If you haven't clearly defined the output destination and the review process before the build starts, you'll pay for that ambiguity in rework.

If you're in between — a business architect, a technical strategist, someone who can build but also needs to justify it: Your ratio is the most expensive. You context-switch constantly between strategic decisions and technical execution. You lose time every time you cross that boundary. For this group, the highest leverage investment is not learning to debug faster — it's being clearer about scope before you open the build tool.

I sit in the third category. I built this myself, which meant I carried both the strategic decisions and the technical execution simultaneously. It was educational and inefficient in roughly equal measure.

What I built

The workflow was conceptually simple:

1. Read published articles from my Notion database
2. Send each one to Claude with two different prompts — one tuned for LinkedIn, one tuned for YouTube Shorts
3. Save the outputs to a review queue in Notion
4. Mark each article as processed so it's never repeated

Four nodes. One-direction pipeline. I expected it to take two hours. It took a full day.

Lesson 1: Reliability has to be matched across components

I had a paid PostgreSQL database ($7/month — always on, always reliable) connected to a web server on a free tier that went to sleep after 15 minutes of inactivity.

The database was reliable. The app was not. Every time I paused between steps, the server slept, and the next execution silently failed.

The fix was simple: upgrade the app server to match the database tier. Seven dollars a month. I had been paying for reliability in one layer while leaving the other layer unprotected.

For technical builders: Match your reliability tiers across every component before you build anything on top of them. The weakest component sets the reliability of the whole system.

For business leaders: Ask this question before any AI initiative goes live: what is the least reliable component in this system, and what happens to the whole thing when that component fails?

Lesson 2: Connecting effort to the wrong output channel

The workflow ran. Every node executed. The execution log showed green across the board. Nothing happened.

After an hour of investigation, I found the issue: the connection was wired to the "Done" branch of a processing node instead of the "Loop" branch. The Done branch only fires when all items are finished. The Loop branch fires for each item as it's processed.

The automation did exactly what I told it to do. I had told it the wrong thing.

For business leaders: You do this constantly — not in workflow tools, but in organizations. A well-resourced initiative that routes output to a reporting function instead of a decision-making function. A feedback mechanism that produces data nobody acts on.

Lesson 3: Two specialized prompts beat one general prompt

I called Claude twice for each article. Once for LinkedIn. Once for YouTube Shorts.

LinkedIn content is read silently. Analytical tone works. Structured paragraphs work. Long sentences are fine.

YouTube Shorts is spoken aloud at normal speaking pace. Short sentences. Natural pauses. A hook that works in three seconds when someone's thumb is moving.

The same article, the same core insight, rendered completely differently for each platform. A single generalised prompt would have produced something that half-worked for both. Two specialised prompts produced something that fully worked for each.

This is not an AI insight. It's an architecture principle: don't build one thing that does everything. Build two things that each do one thing well.

Lesson 4: The real cost of AI automation is not compute

The entire pipeline costs less than $10 a month in API charges at my publishing volume. The infrastructure around it — the server, the database, the hosting — costs $40 a month.

For organizations spending significant time on model pricing, token costs, and vendor licensing — redirect some of that energy. The expensive part of production AI is not the model. It's the integration work, the infrastructure maintenance, and the time required to make something run reliably every day instead of just running once in a demo.

The demo is cheap. The daily run is where the cost lives.

Lesson 5: Design for the decision you haven't made yet

I needed an approval step. But I didn't know whether I wanted that review via email, Slack, or something else.

Rather than block the build on an undecided decision, I designed a placeholder: a webhook wait node that pauses the workflow until triggered externally.

This is called designing for swap-ability. When you reach a decision point in a build and the right answer isn't clear yet, don't guess and don't block. Design a clean interface — a placeholder that will accept whatever the right answer turns out to be — and move forward.

The bottom line

The AI part of an AI automation pipeline is the easy, cheap, and fast part.

The hard part is everything around it: matched infrastructure, correct routing, clean data extraction, and a design that holds up under daily use.

Whatever your role — builder, commissioner, or strategist in between — the ratio that matters is not AI vs non-AI. It's the ratio of clear thinking before the build versus rework after it.

---

Cup of Wit is a newsletter about AI strategy and business architecture — for leaders who want to think clearly about AI without the buzzwords.