n8n Business Automation

n8n is a tool I respect more the more I use it. It’s ugly when you first open it. It’s extremely useful once you stop fighting the visual editor and treat it as a programming environment that happens to have boxes and arrows.

The trick was figuring out which workflows belonged in n8n at all. Anything with non-trivial branching or real error handling started to feel cramped, and I’d move it into a small Node service. Anything that was just “when X happens, call Y, then Z” lived very happily in the visual editor and stayed editable by people who weren’t me. That last point is the actual reason to use a tool like this, handing real workflow ownership to people who shouldn’t have to read TypeScript to change a step.

Self-hosting was the right call for me. The cloud version is fine and probably the right answer for most teams, but having the database and the credentials in my own infrastructure made it much easier to debug, much easier to back up, and much easier to migrate later. The first time a workflow processed something sensitive I was glad I’d gone that route.

The custom nodes were where things got interesting. A handful of the workflows needed logic that would’ve been miserable to express in the visual editor, sliding-window deduplication, recursive lookups, retries with custom backoff. Writing those as proper TypeScript nodes and dropping them into the palette was the moment n8n stopped feeling like a no-code tool and started feeling like a real toolkit.

If I were starting over, I’d be much stricter about that boundary from day one. Trying to express complicated logic in a visual workflow is one of those decisions that feels clever and ages poorly. The visual editor is not a programming environment, it’s a staging ground for handoff. The rule I settled on: if you’d struggle to explain what a node does in a single sentence, that node belongs in code.