During this project, I kept asking myself: “Is it normal that n8n behaves like this?” Short answer: Yes. Completely normal. What this project reinforced: 1. n8n does not guarantee upstream data propagation 2. Data correctness requires intentional merge strategies 3. “No value” is not treated as an error by default 4. Execution continues unless you explicitly stop it This is the reason my workflows include multiple rounds of verification and validation. Not because the logic is complex — but because silent failure is worse than hard failure. n8n is designed to execute, not to protect assumptions. Once you accept that, validation-first design becomes natural.

This post documents a complete intake & validation pipeline built with n8n. Core objective: Ensure that only valid, unique, and file-available YouTube upload jobs enter the system. What’s covered - Google Sheets date-based intake - Data sanitization & validation - Google Drive file existence check - Merge behavior (Combine by Position) - Idempotency key strategy - MySQL schema & duplicate prevention - Why this workflow is safe to run repeatedly Included files - ✅ Workflow JSON - ✅ MySQL table schema - ✅ Installation guide - ✅ Sample input data This is designed as a foundation workflow — the actual YouTube upload worker comes next. If you’re learning n8n for real-world systems (not demos), this pattern is worth mastering.

I’m changing the format a bit. Rather than starting with tutorials, I’m going to: 1. Research workflows that actually help businesses 2. Understand why they exist 3. Share them as real, reusable patterns The goal isn’t to teach nodes. It’s to design workflows that: - reduce manual work - remove risk - or unblock growth Tutorials will still come — but they’ll be grounded in business value first.

After actually building and running workflows with n8n, I’m more confident using it in real business processes. From a senior developer’s perspective, the value isn’t speed alone. It’s clarity. Keeping core logic in code while moving orchestration and integration concerns into workflows has made systems easier to reason about and easier to operate. I’ll keep pushing deeper and stress-testing where n8n makes sense — and where it doesn’t. But there is a real advantage here, especially when it’s applied with proper engineering discipline. Looking forward to sharing concrete examples as I continue building in public.

I’m starting to believe most “AI workflow problems” aren’t AI problems at all. They’re workflow problems. Over the last few months, I’ve seen (and built) many automations where AI is used everywhere: - AI decides routing - AI validates inputs - AI handles edge cases - AI becomes the logic At first, it feels powerful. In practice, it quickly becomes messy. When AI logic is scattered across a workflow: - Failures are hard to trace - Decisions are hard to explain - Debugging turns into guesswork - Reliability drops under real usage The system doesn’t become smarter — it becomes fragile. Lately, I’ve changed how I design automation workflows. Workflow first. AI second. Always. I now try to design workflows that: - Make sense even without AI - Have explicit inputs and outputs - Use deterministic logic for control flow - Fail in predictable, debuggable ways Only after that do I add AI — and only where uncertainty is actually useful. In practice, I prefer AI for: - Classification (with confidence thresholds) - Drafting and summarization - Suggestions, not final decisions - Assisting humans, not silently replacing logic Tools like n8n make this painfully obvious. When everything is visible node by node, there’s nowhere to hide bad design. A thought I keep coming back to: If removing AI completely breaks the workflow, the workflow was never solid. AI doesn’t fix messy systems. It amplifies them. Curious how others are thinking about this: Where do you intentionally refuse to use AI — even though you could?