There's a workflow in your n8n instance right now that nobody dares to edit. It has 43 nodes, seven of them are labeled "Function (old)" and "Function (old 2)," and the person who built it left the company in March. It processes invoices, mostly. Every second Tuesday it silently drops one, and someone in finance has a calendar reminder to check. This is the complexity ceiling, and it arrives without an announcement.
Teams argue the n8n vs custom code automation question like a religion, when it's really an engineering trade-off with knowable terms. Visual workflow tools are genuinely excellent at a specific job: gluing SaaS products together fast, with a diagram your ops lead can read. They are genuinely bad at a different job: being the load-bearing core of a business process that has to fail loudly, test cleanly, and survive staff turnover.
The short answer: keep n8n for the edges (triggers, notifications, glue between third-party APIs) and move the core business logic to custom code when a workflow becomes critical, branches deeply, or scares people. The hybrid pattern, n8n as the trigger layer calling a real API you own, gives you the visual plumbing and the testable core at the same time. Migrate one workflow at a time, shadow-running the new code against the old, and nobody's Tuesday gets interrupted.
Where n8n earns its keep
Credit where due: n8n is one of the best two-week wins in the automation world. Stripe webhook fires, normalize the payload, create the customer record, ping Slack, update the spreadsheet someone refuses to delete. An afternoon of dragging nodes and a process that used to eat three hours a week just stops existing. For glue work between services that already have APIs, the visual canvas is often faster than code and easier to hand to a semi-technical ops person.
The other legitimate superpower is exploration. When you don't yet understand the process you're automating, a visual workflow lets the ops team see their own logic and correct it. We've watched office managers point at a node and say "that step is wrong, returns go to Karen first." That conversation is harder to have over a Python file. n8n as a shared sketchpad for the process, before the process hardens, is a legitimately great use.
The complexity ceiling
That ceiling arrives along three axes, and they compound. First, branching logic: past a dozen conditional paths, the canvas stops being a diagram and becomes a plate of spaghetti with a webhook at one end. Second, failure handling: a retry storm from a flaky third-party API, a node that fails silently at 2am, an error branch someone added and never wired to an alert. Third, versioning: "Function (old 2)" is not version control. There's no meaningful code review, no test suite, no diff your next engineer can read.
The tell is always the same: a workflow that matters to the business and that everyone is afraid to touch. Fear is the smoke alarm. When editing the invoice workflow feels like defusing a bomb, the workflow has outgrown the tool, whatever the node count says.
n8n vs. custom code automation: the decision framework
Four axes, weighed honestly, settle most n8n vs custom code automation debates in one meeting:
- Criticality. If a silent failure costs real money or a customer, it needs tests, alerts, and code review. That's custom code territory.
- Branching depth. Linear glue between APIs stays in n8n. Deep conditional logic, loops over line items, state machines: code, and not close.
- Volume. Fifty executions a day forgives anything. Fifty thousand a day makes per-execution pricing and runtime limits part of your architecture.
- Maintenance. If the honest answer is "whoever replaces the person who built it," choose the thing with a test suite and a README.
Score it and the pattern is consistent: n8n wins the corners (low criticality, shallow logic, glue between services), code wins the core (high criticality, deep logic, business-owning processes). Most companies have both kinds, which is convenient, because the answer is usually both. The same calculus shows up in the Retool vs. custom build decision: visual tools for speed and internal surfaces, code for the parts that own the business.
The hybrid pattern that actually works
The architecture that survives contact with reality: n8n owns the edge, code owns the core. Concretely, n8n keeps doing what it's good at, catching the webhook, watching the inbox, firing on the schedule, and then it calls an HTTP endpoint you own. That endpoint is a small, boring service with the actual business logic: validated, tested, logged, deployed like software instead of arranged like furniture.
This split keeps the ops-readable diagram (the trigger flow is still visible in n8n) while the scary parts live where scary parts belong. It also plays well with the rest of a lean stack; the same service layer slots into the FDE stack essentials next to your database and queue, and if you're generating the glue scripts themselves, the Python automation patterns FDEs rely on translate directly. One more boundary worth drawing: when a workflow step calls an LLM, that call belongs behind your own API too, and choosing an LLM API is a decision you'll want versioned in code, not buried in a node.
Migrating without a flag day
Never rewrite the workflow and flip the switch on a Friday. The strangler approach works like this: build the new endpoint, then run it in shadow mode, where the n8n workflow keeps executing as before but also calls the new code and logs any disagreement between the two outputs. A week of shadow-running on real traffic tells you exactly where your understanding of the process was wrong, and it will be wrong somewhere. Fix the disagreements, then cut over, one workflow at a time, keeping the old one disabled but intact for a month as a panic button.
Order the migration by scariness, smallest first. The first migration teaches you the pattern; the invoice monster goes last, after the team trusts the process. Budget roughly one to three days per workflow depending on how much undocumented cleverness is hiding in the Function nodes.
The cost math nobody does
The pitch for visual automation is that it's cheaper than engineering time, and at five workflows it is. The math nobody does is the maintenance curve. In an illustrative but realistic tracking of a growing automation estate, an n8n-only shop hits about 45 active workflows and finds itself spending 60 hours a month on workflow maintenance: debugging silent failures, updating credentials, untangling edits. The hybrid shop at the same count spends about 15, because the scary logic lives in tested code and the workflows left in n8n are the simple ones.
Sixty hours a month is half an engineer, spent defusing bombs instead of building. That's the number to put next to the subscription price when someone calls the visual tool "free." The tool was never the expensive part. The fear was.
Start with the audit: list your workflows, mark the ones people are afraid to edit, and shadow-run a replacement for the smallest scary one this month. The diagram stays. The bomb goes.