Every few months a client asks us some version of the same question: should we build on n8n, Make, or Zapier? The question usually arrives after someone on the team has watched a demo, and demos are the worst possible basis for this decision. All three platforms look identical in a fifteen-minute walkthrough. The differences that matter show up in the invoice, in the debugging session at 4pm on a Friday, and in the conversation with your accountant about where customer data lives.
This is the framework we use when we scope an automation backbone for a client. It is not a feature comparison. Feature lists for these three platforms converge a little more every quarter, and by the time you read one it is out of date. What does not converge is the pricing model, the deployment model, and the operational habits each platform forces on you. Those are the things that decide whether your automation estate is healthy in eighteen months or quietly rotting.
The real differences, in the order they actually bite
Pricing model: tasks and operations versus executions
This is the first thing to understand, because it shapes everything else, including how your team designs workflows.
Zapier bills per task. A task is one action step firing once. A five-step Zap that runs a thousand times a month consumes roughly four thousand tasks (the trigger is free, each action is not). Make bills per operation, which is similar in spirit: each module execution counts, including the trigger and including internal tools like routers and iterators in some paths. n8n bills per workflow execution on its cloud plans — one run of the whole workflow, whether it has three steps or thirty, counts once. And if you self-host n8n, there is no per-execution meter at all; you pay for the server and your time.
The practical consequence is that the same workflow can differ in cost by a factor of ten or more depending on where it runs. It also changes design incentives. On Zapier and Make, there is a quiet pressure to build fewer, fatter workflows and to avoid polling triggers that fire often. On n8n, the marginal cost of one more run is effectively zero, so people build more, smaller, more honest workflows — which is usually better engineering.
We see the pricing surprise most often with loops. A Make scenario that iterates over two hundred rows in a spreadsheet and does three things per row can consume six hundred-plus operations in a single run. A client of ours in distribution had a daily inventory sync that looked modest on paper and was consuming the bulk of their monthly operations allowance because of exactly this pattern. Nobody had done the arithmetic before building it.
Self-hosting and data residency
Zapier and Make are hosted services. Your data transits their infrastructure, full stop. For most SMBs this is fine — both have mature security postures, and for a marketing agency moving leads between a form and a CRM, the risk calculus is simple.
It stops being simple when you handle health data, financial records subject to specific residency rules, or client data under contractual residency clauses. We work with a manufacturer whose ISO 27001-driven policies make "data flows through a third-party SaaS we cannot audit" a hard conversation. For them, n8n self-hosted on infrastructure they control is not a preference, it is the only option of the three. Self-hosting n8n is genuinely manageable — a small VPS, Docker, a few environment variables — but it means you now own patching, backups, uptime, and queue tuning. That is real operational responsibility, roughly a few hours a month for a competent technical generalist, and it should be priced into the decision.
Make offers a European data center, which solves some residency questions but not audit-control questions. Zapier is US-hosted across the board as of this writing. If your compliance needs are contractual rather than regulatory, sometimes a conversation with the client's legal team resolves it. Sometimes it does not, and you should know which before you build.
Code escape hatches
Every real automation eventually hits the edge of what drag-and-drop can express: a gnarly date calculation, a weird XML payload from a legacy system, a deduplication rule that needs an actual algorithm.
All three platforms let you drop into code, but the experience differs. n8n's Code node runs JavaScript or Python, has access to the full item stream, and feels like a first-class citizen — you can also just write expressions anywhere, and power users end up writing a lot of them. Make has custom functions and a JavaScript module (on higher tiers), workable but noticeably more constrained. Zapier has Code by Zapier steps in JavaScript or Python, which are fine for small transforms but awkward for anything stateful or heavy.
The deeper point: on n8n, the ceiling is high enough that we rarely have to say "the platform cannot do this." On Zapier, we say it a few times a year, and the answer becomes a small Lambda-style function on Pipedream or a webhook to a service we control. That hybrid pattern works, but it is a seam in the system that someone has to remember exists.
Debugging and error handling
This is where platforms earn or lose our trust, because automations fail — the question is how painful the failure is to find and fix.
n8n gives you full execution logs per node, the ability to pin input data and re-run a single node, and the ability to re-execute a failed run from the point of failure after fixing it. For a production estate, this is the gold standard among the three. Make's execution inspector is also strong: you can see the exact bundle that flowed through each module and replay runs. Zapier's task history is serviceable for simple Zaps — you can see what went in and out of each step and replay failures — but on long, branched Zaps with filters and paths, tracing why a specific record took a specific route is noticeably more painful. We budget roughly twice the debugging time on complex Zapier builds for this reason.
Error workflows matter too. n8n lets you attach a dedicated error workflow to any workflow — a global "if anything fails, do this" that we point at a Slack channel and an Airtable log on every client build. Make has error handling per module (ignore, resume, rollback, break with retries). Zapier's story is thinner; most teams learn about failures from a client, which is the worst monitoring system there is.
Ecosystem depth
Here Zapier still leads on raw numbers — several thousand app integrations, and for obscure SMB SaaS tools it is often the only one of the three with a native connector. Make is a strong second and typically goes deeper per app (more endpoints exposed, more triggers). n8n's native library is smaller but growing fast, and because every node is effectively an HTTP client under the hood, anything with a documented API is reachable. The community template and node ecosystem helps, though quality varies.
Our rule of thumb: if the client's stack is five or more niche SaaS tools and nobody technical will maintain the workflows, Zapier's breadth is worth real money. If the stack is mainstream (Shopify, Xero, Airtable, Slack, Google, Microsoft), all three cover it and breadth stops being the deciding factor.
AI steps, since it is 2026
All three platforms now ship AI-native building blocks — model calls as steps, agent-style tool use, prompt templates. n8n has leaned hardest here, with LangChain-style nodes that let you wire a model to tools and memory inside a workflow, which is genuinely useful for document extraction and classification steps. Zapier and Make both offer AI steps that are fine for drafting and summarizing inside an otherwise deterministic flow.
Our position, which we hold regardless of platform: an AI step is a component, not a strategy. The useful pattern is a deterministic workflow with one or two well-guarded model calls in the middle — extraction, classification, a draft for human review — not an "agent" wandering your systems unattended. Choose your backbone on pricing, deployment, and debugging. The AI features are close enough across all three that they should not drive the decision, and the guardrails that make AI steps safe (review queues, validation, fallbacks) are things you build around the platform anyway.
Total cost of ownership at realistic volumes
License cost is the visible number. Ownership cost includes build time, maintenance, debugging, and the salary of whoever gets paged when things break. Still, the license math is worth doing properly once, because it is where budgets get set.
A worked example from a mid-size client estate we manage — a services business, about 35 staff:
- Lead intake and routing: web form to CRM, enrichment, Slack notification, 1,200 runs a month, 6 steps each.
- Invoice sync: invoicing tool to Xero, with line-item transformation, 900 runs, 8 steps.
- Weekly reporting rollups: aggregate from three sources into Airtable, email summary, 130 runs, 12 steps.
- Support ticket enrichment and triage: 2,500 runs, 7 steps.
- Document generation on deal close: 300 runs, 9 steps.
Total: about 5,030 workflow runs a month, roughly 36,000 individual step executions.
On a task-or-operation-metered platform, you are shopping in the tier that covers roughly 40,000 units, which lands in the low-to-mid hundreds of dollars per month on current published pricing — call it 150 to 400 dollars depending on plan and annual discount, and it climbs fast if volume grows or you add polling-heavy workflows. On n8n Cloud, execution-based pricing for 5,000-plus executions sits lower, and on self-hosted n8n the direct cost is a 10-to-30-dollar VPS plus maintenance time. The license delta at this volume is real but not dramatic — maybe a few thousand dollars a year. The bigger TCO lever is maintenance: an estate of twenty workflows needs someone spending three to eight hours a month keeping it healthy regardless of platform, and platform debugging quality directly prices that time.
One more honest note: all three platforms change pricing regularly. We re-run this arithmetic at every renewal. Do the same.
It is also worth pricing the failure modes, not just the plans. A workflow that fails silently for three weeks and corrupts a reporting rollup costs more than any license tier. We have seen a single unnoticed duplicate-invoice bug cost a client more in cleanup than two years of platform fees. When you compare platforms, include the debugging time and monitoring quality in the spreadsheet, even if you have to estimate them. They are not soft costs; they are the costs that actually arrive.
Migration costs and lock-in
Nobody budgets for the second platform, but about a third of our engagements start with "we built on X and have outgrown it." The honest facts:
Workflows do not export. There is no meaningful Zapier-to-n8n converter. Migration means rebuilding, and rebuilding means rediscovering every undocumented edge case baked into the old build. A single workflow migrates in hours. An estate of thirty workflows, with testing and parallel running, is a multi-week project.
The mitigations are boring and effective. Keep a written register of every workflow: what it does, what triggers it, what breaks if it stops. Keep business logic out of platform-specific glue where you can — a rule encoded in an Airtable formula or a small documented script survives a platform change; a rule encoded in a chain of Zapier filters does not. And store your data in systems you own (Airtable, Baserow, Xero), not in platform-internal storage like Zapier Tables, for anything you would miss.
Lock-in is rarely about the vendor being malicious. It is about the accumulation of small, forgotten dependencies. The discipline above is what keeps your exit cost low.
How we choose: a decision framework
When we scope this for a client, we ask five questions in order:
- Data residency or audit requirements? If yes, self-hosted n8n, conversation over.
- Is anyone technical going to own this? If no internal or retained technical owner exists, favor Zapier for breadth and simplicity, or engage a partner to own a Make or n8n build.
- What is the realistic monthly execution volume and step count? Do the pricing arithmetic on the actual numbers, not the marketing tiers.
- How complex will the workflows get? Loops, branches, error handling, code — if the answer is "very," n8n or Make. If it is "mostly two-to-four-step handoffs," Zapier is often genuinely the right tool.
- What happens when it fails? If silent failure is unacceptable, weight debugging and error-workflow quality heavily. That pushes toward n8n or Make.
Three archetypes from recent engagements:
The 12-person agency. Lead intake, proposal generation, client onboarding, reporting. Stack is mainstream SaaS, nobody on staff is technical, volumes are a few thousand runs a month. We put them on Make or Zapier depending on how many niche tools are in the stack, keep every workflow under eight steps, and retain a light support arrangement. The platform matters less than the discipline of keeping workflows small and documented.
The manufacturer with compliance needs. Forty staff, ISO 27001, contractual data residency clauses, an ERP with a mediocre API, and workflows that need real code and real error handling. Self-hosted n8n, error workflows wired to a monitored channel, a written register of every automation, and quarterly reviews. Higher operating discipline, but it is the only option that survives their audit conversations.
The solo founder. Twelve Zaps' worth of needs, no budget for anything fancy, volume in the hundreds of runs a month. Zapier's free or starter tier, full stop. The advice we give is not about the platform — it is about not building the sixteenth Zap until the first fifteen are written down somewhere. The failure mode for solo founders is not cost, it is a fragile web of automations only they understand.
The one we would add: the growing SMB crossing 50 staff. This is the archetype that most often needs to migrate. They started on Zapier because it was easy — correctly — and now they have forty Zaps, a bill that crept past 500 dollars a month, and workflows nobody can debug. Our usual recommendation is Make or n8n depending on technical ownership, a phased migration starting with the five most painful workflows, and a hard rule that no new builds go on the old platform.
Where to start
If you are choosing a backbone today, do the five-question pass above with honest answers, run the cost arithmetic on your real volumes, and build one representative workflow on your shortlisted platform before committing the estate. A week of deliberate testing beats a quarter of regret.
If you would rather have an outside read on it, book a 30-minute audit — we will map your current workflows, price them on each platform, and tell you plainly whether you should switch, stay, or split the estate.