We've shipped enough n8n to have opinions. The opinions:
n8n is a great tool that's used wrong about half the time. The split between "this saved the project" and "this is now a maintenance burden" comes down to a few specific patterns.
When n8n is the right answer
1. Glue between SaaS tools you don't control
You have Stripe, HubSpot, Slack, and Google Sheets. You want a thing that happens when X. You're not going to build a custom backend for it. n8n is a perfect glue layer for this — visible, debuggable, easy to change when the requirements drift in three months.
2. Multi-step workflows with human review in the middle
A new lead arrives. The system enriches it, scores it, drafts a reply, waits for someone to approve the reply, then sends it. n8n's native support for waits, approvals, and webhooks makes this kind of workflow much cheaper to build than the equivalent in code.
3. Throwaway automations under 50 nodes
Quick, scrappy, save-an-hour-a-day automations. n8n is genuinely faster than writing a script for these.
When n8n is the wrong answer
1. Anything that needs to be tested
n8n workflows are not testable in any reasonable sense. You can run them with mock data, but the version-control story is brittle, the diff readability is awful, and there's no concept of unit tests. If the logic is critical and likely to change — write code.
2. Workflows over 100 nodes
After about 100 nodes, an n8n flow stops being a system you can reason about and starts being a swamp. The handoffs between nodes become invisible, the edge cases multiply, and any change risks breaking three things you forgot existed.
If your workflow is over 100 nodes, you don't have an automation. You have an undocumented application written in JSON.
3. Things that need to be fast
Cold starts, queue latency, and webhook overhead add up. If your workflow needs to respond in under 200ms, n8n is the wrong shape.
4. Anything you'd be embarrassed to hand over
The day a client asks "can we move this in-house" is the day you regret writing 400 nodes worth of business logic in n8n. You can't. You'd have to rewrite it. So write it as code in the first place if it's the kind of thing the business will own.
How we decide
The test we run on every workflow:
Will this still exist in two years, and will someone other than us need to change it?
If yes to both: write code. If yes to one and no to the other: depends on which one. If no to both: n8n.
That's it. That's the rubric.
The honest take
n8n is a tool. It's not a strategy. The agencies that brand themselves as "n8n shops" are doing their clients a disservice — they're going to pick n8n for everything because it's the hammer they have.
We pick the tool after we understand the problem. Sometimes it's n8n. Sometimes it's a Python script. Sometimes it's a real backend. The point is the question got asked.