Every automation starts innocent. There’s a clear goal, a clean trigger, and a straightforward path to completion. The first few nodes feel obvious and harmless. Each addition solves a real problem in front of you. Then “just one more node” quietly becomes the story of how maintainability dies.
n8n workflows don’t feel complex while you’re building them; they feel incremental. Each change is small, local, and visually contained within a box or branch. Because nothing breaks immediately, the system feels stable even as complexity accumulates. That stability is misleading.
Complexity doesn’t grow linearly; it compounds invisibly. Conditionals spread across branches. Error handling forks in slightly different ways. Retry logic mutates as edge cases pile up. Eventually, behavior depends more on node order than on meaning.
By the time something fails, no one remembers which decisions were intentional and which were expedient. The system still works, but no one knows why. That’s the danger zone.
Code creates friction in exactly the places you want it. You hesitate before adding another conditional because you can feel the complexity growing. You extract functions because reading the same logic twice feels wrong. You notice when a file becomes uncomfortable to scroll through.
That discomfort is not a failure, it’s feedback. It tells you when the design needs attention instead of more features. Code surfaces structural problems early, while visual tools tend to hide them until they’re expensive.
With code, refactoring is a first-class operation. You can rename concepts, extract responsibilities, collapse duplication, and verify behavior with tests. In visual workflows, refactoring often means rebuilding, and rebuilding feels risky even when it shouldn’t.
I’ve seen n8n workflows that worked perfectly and terrified everyone. They had no tests, no versioned logic, and no confidence around upstream changes. The workflow wasn’t fragile; but, the understanding of it was.
When I rewrote one as a service, the biggest surprise wasn’t how much code it took. It was how much less anxiety it produced. Changes felt deliberate instead of dangerous.
That’s when it clicked for me: fear is a design smell. If no one wants to touch it, the system is already broken… just not loudly yet.
Incremental changes can hide exponential complexity
Refactoring is easier and safer in text than diagrams
Fear is often the first signal of technical debt
If you’ve ever said “don’t touch that workflow,” this one’s for you.
Subscribe, and tell me what system you’re quietly afraid of.