n8n vs Zapier: when to use each (and when to write code instead)
Both are great automation tools. They solve different problems. Here's the framework I use to pick one.
I've shipped serious automation work in both n8n and Zapier. Clients always ask me which one to pick. The honest answer is: it depends on who maintains it after I'm gone.
The fundamental difference
- Zapier is a managed SaaS. Click, drag, ship. Their team handles the runtime.
- n8n is open-source software. You can self-host or use their cloud. You own the workflows and the runtime story.
Everything else flows from that.
Pick Zapier when
- Non-technical operators will maintain the flows. Zapier's UI is forgiving; n8n's is more powerful but less hand-holdy.
- You're connecting tools you don't run. Slack ↔ Notion ↔ HubSpot ↔ Sheets. Zapier's catalog is enormous and the integrations are reliable.
- Volume is moderate. Zapier's pricing scales with task count, and "task" can be deceptively expensive at high volume.
Pick n8n when
- You want to self-host. Compliance, latency, or cost arguments.
- You need real branching logic. n8n's expression engine and code nodes beat Zapier's path filters.
- The flow has many steps with retries and queue semantics. n8n handles this much better.
- You'd like to fork the codebase someday. It's MIT-style licensed.
Building a 30-step n8n flow when 5 of those steps deserved to be in code. The flow ran. It also became un-debuggable. Now I follow the rule: if you're writing more than ~20 lines of expression logic in one node, that node belongs in code.
Pick code (a real service) when
This is the part most automation guides skip. Sometimes the right answer is neither Zapier nor n8n.
Reach for code when:
- The logic is the product. Don't put your differentiator in a no-code tool.
- You need real test coverage. Yes, you can test n8n flows, but not the way you can test a Jest suite.
- Performance matters. n8n adds overhead. For a hot path serving customers, write the service.
- The data model is complex. Multi-tenant isolation, audit logs, type-safe DTOs — these belong in code.
A real example
On the Content Engine project, I split it like this:
- NestJS owns: topic generation, prompt assembly, render orchestration, feedback loop math, multi-tenant isolation.
- n8n owns: distribution to TikTok / IG / LinkedIn / YouTube, captions, scheduling.
Why? Because the agency's ops team needs to tweak the distribution rules ("post at 9am EST on weekdays, 11am on Saturdays"). They can't tweak Jest tests. They can tweak n8n.
But putting the whole pipeline in n8n would have made the core un-testable.
The one-question heuristic
Before reaching for either tool, ask: "who maintains this in 6 months when I'm not here?"
- A non-technical ops team? → Zapier, or n8n with very disciplined naming
- A small dev team? → n8n or code
- Just me? → whichever ships fastest, then refactor the parts that hurt
Honest answer beats brand loyalty every time.
If you're staring at a manual workflow and not sure where it should live — happy to compare notes. The short version: most teams reach for Zapier when they should be writing code, and reach for code when Zapier would be fine. Match the tool to the change rate of the workflow, not the size of it.
Hiring for something this touches?
Send a note — happy to dig into the architecture and trade-offs.