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:

Read published articles from my Notion database
Send each one to Claude with two different prompts — one tuned for LinkedIn, one tuned for YouTube Shorts
Save the outputs to a review queue in Notion
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? The answer usually reveals an assumption nobody made explicit. I've seen organisations invest in enterprise data infrastructure then connect it to manual approval processes that bottleneck every workflow. The investment is real. The outcome isn't.

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. I had wired the work to the channel that only opens after everything is already complete.

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

For technical builders: When a workflow runs successfully but produces no output, check which branch your downstream nodes are connected to before looking anywhere else. This is the most common silent failure in loop-based automation.

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. The effort is real. The routing is wrong. Before you build any process, define not just what it produces but exactly where that output goes, in whose hands, and what action it triggers.

Lesson 3: Two specialized prompts beat one general prompt

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

This was a deliberate architectural choice — and the right one.

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. The cost difference is negligible. The quality difference is significant.

For business leaders evaluating AI tools: When a vendor tells you their AI can "do everything," ask what it's actually optimized for. Generalized models produce generalized output. If you need outputs for different audiences, contexts, or formats — design separate workflows for each one.

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

The entire pipeline — reading Notion, calling Claude twice per article, saving outputs — 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 — a way to review Claude's output before anything gets posted publicly. 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. When I decide on the notification method, I swap in that component without changing anything else in the pipeline.

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 decision will become clear once you see the system running.

The cost of designing for swap-ability upfront is small. The cost of rebuilding when you've hardcoded the wrong answer is large.

What I'd do differently

Match infrastructure reliability first. Before writing a single workflow node, confirm that every component in your stack has matched reliability. An always-on database deserves an always-on app server.

Test one node at a time. The temptation is to build the whole workflow and run it end to end. The result is an error you can't locate. Confirm each node produces the right output in isolation before connecting it to the next one.

Name everything as if someone else will maintain it. You will reference nodes by name in expressions across the workflow. That someone else is usually you, six months later, with no memory of what you built.

Define the output destination and owner before you build. Know where the output goes, in whose hands, and what action it's supposed to trigger. If you can't answer that question before building, the pipeline will run reliably into a void.

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.

That ratio is entirely within your control. The debugging is not.

Cup of Wit is a newsletter about AI strategy and business architecture — for leaders who want to think clearly about AI without the buzzwords. If this was useful, you know what to do.