YouTube Content Automation
A content pipeline that takes an idea to a finished, review-ready asset with the human kept firmly in the approval seat. The videos weren't really the point. I wanted to build it as a pattern I could write down and run again.
How it works
- A Python pipeline orchestrated through n8n, with PostgreSQL holding a normalized schema and parameterized queries.
- OAuth2 and API-key auth, webhook-driven workflows, and Claude API doing the generation work.
- A review gate where I approve or reject before anything ships. 90% of generated content clears it.
The real deliverable
I built this in the open and wrote it down as I went. That documentation is the actual product: a repeatable deployment pattern someone else could follow, which is exactly what an FDE is supposed to extract from a deployment and hand back to the team.
The pattern was the point, not the videos.
This one looks like a content pipeline. What I was actually building was something I could write down and run again. Three decisions that say why.
Why the documentation is the real deliverable
The videos were never the prize. A forward-deployed engineer's job isn't to do the thing once, it's to leave behind a pattern the team can run after you've gone. So I built this in the open and wrote down every decision as I made it, and that write-up is the actual product: a repeatable deployment someone else could follow without me in the room. A pipeline that only its author can run is a liability. One that's documented well enough to hand off is an asset.
Why a human still approves everything when 90% passes anyway
Nine out of ten generated pieces clear the review gate, which is exactly the number that tempts you to remove the gate. The reason it stays is the tenth. The cost of shipping good content is roughly zero, and the cost of shipping the one bad piece under your own name is not, so the math is lopsided no matter how good the model gets. The gate isn't there because the AI is unreliable. It's there because the downside is asymmetric, and that's a different and more permanent reason.
Why n8n and Python instead of picking one
I could have written the whole thing in Python or built the whole thing in n8n, and either would have run. I split them on purpose: n8n holds the orchestration, the webhooks and the flow you want to see at a glance, and Python holds the logic that's genuinely easier to read and test as code. Forcing complex logic into a visual tool, or hiding the high-level flow inside a wall of script, both work and both age badly. Putting each part where it's legible is what you'll thank yourself for when you come back to change it in six months.