Zapier, n8n or custom automation: when to graduate

Three levels, not three rivals

Zapier, n8n and custom code are best thought of as levels that an organisation moves through as automation becomes more important to it. Zapier is the fastest way for anyone to connect two apps. n8n is a workflow tool for technical teams that want more control, more logic and more predictable costs. Custom automation is ordinary software: services, queues and scheduled jobs written in code, tested, deployed and monitored.

Moving up a level is not a sign that the previous tool failed. Most organisations should keep using Zapier for small, low-risk tasks long after they have moved their critical flows elsewhere. The skill is knowing which workflows have outgrown their home.

How the pricing models differ

The biggest practical difference between Zapier and n8n is what you pay for. At the time of writing (October 2026), Zapier charges by task. A task is a successful action step, so a single run of a five-action Zap uses five tasks. Triggers, filters, paths and several built-in utilities do not count, and failed actions do not count. Plans are sold in task tiers, and if you enable pay-per-task, usage beyond your tier is billed at a higher overage rate until it pauses at three times your subscription.

n8n charges by execution: one full run of a workflow, however many steps it has. Its cloud plans include unlimited users and workflows and differ mainly in execution volume, concurrency and governance features. The Community Edition can be self-hosted at no licence cost under the Sustainable Use License, while features such as SSO, environments and Git-based version control need a paid Business or Enterprise licence.

In practice this means long, multi-step workflows running at high volume get expensive on Zapier much faster than on n8n. Short, simple flows at low volume cost little on either.

When Zapier is enough

Zapier is the right answer more often than engineers like to admit. It connects to thousands of apps, the people who understand the process can build the automation themselves, and a two-step Zap that posts new leads to a channel or copies form entries to a spreadsheet does not need anything more.

Stay on Zapier while three things hold: the workflows are short, volumes are modest, and a failed run is an annoyance rather than an incident. Zapier holds runs when you hit your task limit and lets you replay them from Zap history, and its flood protection asks you to confirm when a polling trigger suddenly produces a large batch of events. These are sensible safeguards for business automation, not substitutes for engineering controls on a payment flow.

• Marketing and sales operations: leads, notifications, CRM updates.
• Internal admin: copying data between SaaS tools, creating tasks, sending reminders.
• Prototypes: proving that an automation is worth having before investing in it.

When to move to n8n

n8n makes sense when your automations start to look like programs. You need loops over hundreds of records, real branching, calls to internal APIs, a little JavaScript or Python, or AI steps chained together. Because n8n bills per execution rather than per step, a forty-step workflow costs the same to run as a two-step one, which changes the economics of complex flows.

Self-hosting is the other common reason. If customer or financial data must stay in your own infrastructure, a self-hosted n8n instance keeps it there. Be clear about what that means: you now run a server. Someone must patch it, back it up, monitor it and scale it. n8n’s own documentation is candid that some installation methods leave dependency management to you.

Read the licence. n8n’s Sustainable Use License allows use for your own internal business purposes and non-commercial use. If you plan to build a product on top of n8n or offer it to your customers, check the terms with n8n before you start.

• Signal: your Zapier bill is driven by a handful of long, high-volume Zaps.
• Signal: you are working around Zapier limits with webhooks and code steps.
• Signal: data residency or security policy requires self-hosting.

When to graduate to custom automation

The move to custom code is driven by risk, not by step counts. When an automation moves money, makes credit or compliance decisions, touches regulated data or runs part of your product, it needs the controls you would expect of any production software: code review, automated tests, separate environments, versioned deployments, structured logs, alerting, and a clear answer to what happens when a step fails halfway through.

Workflow tools can provide some of this, especially on enterprise tiers. What they find hard is the last part: idempotency, retries with back-off, compensating actions and reconciliation. If a payment instruction is sent twice or a ledger update is lost, a replay button is not enough. Custom services built around queues and explicit state make those guarantees testable.

Custom also wins when the automation is part of what you sell. A customer onboarding flow, a lending decision pipeline or a reconciliation engine is product logic. It belongs in your codebase, under your licence, where your engineers can change it with confidence.

• A failure would cause financial loss, a regulatory breach or customer harm.
• Auditors or regulators will ask how the process works and who changed it.
• The workflow needs exactly-once behaviour, reconciliation or long-running state.
• Usage pricing for the workflow now exceeds what it would cost to run as code.
• Only one person understands the workflow, and it lives in their account.

Common failure modes

Automation rarely fails loudly. It fails quietly, at night, and somebody notices a week later when a customer complains or the numbers do not add up. Each level has its own typical problems, and most of them are about ownership rather than technology.

The pattern behind almost all of them is the same: an automation became important without anyone deciding that it was important. A useful habit is to keep a short register of every workflow that touches customers, money or regulated data, with an owner, a description and a note of what happens if it stops. That register is also the best starting point for deciding what to graduate.

• Zaps built in a personal account by someone who has since left, with nobody else able to edit them.
• A connected app changes a field name or its API, and runs start failing until someone notices the error emails.
• A task limit is reached mid-month, runs are held, and a time-sensitive process waits until somebody replays them.
• A self-hosted n8n server that nobody patches or backs up, holding credentials for every system it connects to.
• Workflows that call each other in chains, so that one failure cascades and the root cause is hard to find.
• Custom services built without monitoring, so failures are discovered by customers rather than by alerts.

How to migrate without breaking things

Graduating is rarely a big-bang rewrite. Move one workflow at a time, starting with the one that carries the most risk. Write down what it does today, including the edge cases people handle by hand, because those are the parts a rewrite most often misses.

Run the new version alongside the old one and compare outputs before switching. Keep the triggers stable where you can: if a form or webhook calls Zapier today, point it at the new service and leave the rest of your stack untouched. Once the critical flows have moved, the remaining Zaps usually cost less and matter less, which is exactly where you want them.

Questions

Sources

1. Zapier: Plans and pricing
2. Zapier Help Center: Zap history and replay
3. n8n: Pricing
4. n8n: Sustainable Use License (LICENSE.md)
5. n8n Docs: Hosting n8n