We build most client automation on n8n. But we’ve shipped production work on all three of these, and the honest answer to “which one should we use” is that it depends on two things nobody asks about during selection: pricing shape, and who maintains it after we leave.
Here’s the version of this comparison we’d give a friend, with the parts vendors leave out.
The short version
- Zapier: best when the client’s own staff will maintain it, the volume is low and predictable, and every app you need is already a native integration. Most expensive per unit of work, by a lot, once volume grows.
- Make: best middle ground. Real branching and iteration, visual enough for a non-engineer to follow, priced per operation rather than per task, which is meaningfully cheaper at volume.
- n8n: best when you need real logic, real code, control over where data lives, or predictable costs at volume. Self-hostable. Steeper to learn, and someone has to own the instance.
The pricing thing nobody mentions until month four
This is the single biggest factor, and it’s almost never discussed during selection.
Zapier charges per task, where a task is roughly one action step running once. A five-step Zap firing on 400 leads a month is 2,000 tasks. Fine. Now add a loop over line items, and a filter that runs on every record before deciding most of them are irrelevant. You’re burning tasks on records you discard. We’ve watched a client’s Zapier bill go from about $70 a month to over $600 without anyone adding a new workflow. The business just grew, and the pricing model grew faster.
The specific trap: filters and lookups consume budget. If your workflow checks 500 records to act on 20, you paid for 500. The pricing punishes exactly the defensive, careful design you want in production.
Make charges per operation, which is a similar concept, but the operations are cheaper and the bundles are larger. For the same workload you typically land somewhere in the range of a third to a half of the Zapier cost. Make also handles iteration natively, so processing 30 line items is 30 operations rather than an awkward workaround.
n8n self-hosted charges you for a server. That’s it. A $12–20/month VPS runs a shocking amount of workflow. Their cloud offering prices per workflow execution rather than per step, which means a 40-step workflow costs the same as a 3-step one. It’s a completely different incentive structure: you design for correctness instead of designing to dodge the meter.
Where Zapier genuinely wins
Integration coverage, and it isn’t close. Zapier has native connectors for niche software that n8n will never support: the scheduling tool your client’s industry association mandates, the ancient billing system with the strange auth flow. When the alternative is writing and maintaining a custom HTTP integration yourself, paying Zapier is the correct call.
The other real win is handover. An office manager can open Zapier, understand what a Zap does, and fix a broken field mapping, which is worth actual money. We’ve handed over elegant n8n workflows that broke six months later and then sat broken, because nobody at the company could read them. A slightly worse system the client can maintain beats a better one they can’t touch.
So if we’re building something the client will own and nobody there writes code, we’ll often recommend Zapier even knowing it costs more. The maintenance story wins.
Where Make sits
Make is the tool we recommend most often to clients who want to keep building themselves but have outgrown Zapier. The scenario editor shows you data flowing between modules, which makes debugging far more legible than reading step outputs one at a time.
Its real advantage is structural. Arrays, iterators, aggregators, and routers are first-class. In Zapier, working with a list of line items means fighting the tool; in Make, you drop an iterator in and move on. For anything involving quotes, invoices, or orders, which is most contractor work, that difference shows up immediately.
The downsides are real. Error handling is more fiddly than it should be, the visual canvas that helps at 10 modules becomes a maze at 60, and you’re still on someone else’s cloud, which matters for the compliance conversation below.
Why we default to n8n
Three reasons, in order of how much they matter.
First, cost predictability. Clients hate variable infrastructure bills more than they hate high ones. A flat server cost lets an owner stop thinking about it, and it means we design workflows for reliability instead of for meter-dodging.
Second, the code escape hatch. Every real automation eventually hits something the visual builder can’t express: a date-parsing edge case, a weird string transform, a conditional that needs three levels of nesting. In n8n you drop in a Code node, write ten lines of JavaScript, and continue. In Zapier the same thing means Code steps that are harder to debug and cost tasks. Having that hatch is often what separates a shipped workflow from an abandoned one.
Third, data boundaries. If you’re working with a government contractor, a healthcare adjacent business, or anyone with a contractual obligation about where data lives, self-hosting stops being a preference. Running n8n inside the client’s own environment means customer data never touches a third-party automation vendor. Try getting that answer from a per-task SaaS.
The honest downsides of n8n
It isn’t the easy choice, and we shouldn’t pretend otherwise.
- Someone has to run the server. Updates, backups, monitoring, TLS certificates. If the client has no technical staff, that someone is us, and that’s a retainer, not a one-time build.
- Fewer native integrations. You’ll write HTTP request nodes against raw APIs more often, which is fine if you can read API docs and miserable if you can’t.
- The learning curve is real. The expression syntax is unforgiving and the error messages aren’t always kind.
- Self-hosting means you own the outage. When Zapier goes down, it’s Zapier’s fault. When your n8n box fills its disk with execution logs at 2am, it’s yours.
That last one isn’t hypothetical. Turn on execution data pruning on day one.
How we actually choose
Four questions, in order:
- Who maintains this in a year? If it’s the client and they’re non-technical, weight heavily toward Zapier or Make. This overrides almost everything else.
- Does the data have a boundary requirement? If yes, self-hosted n8n, and the other two are off the table. That one isn’t negotiable.
- What’s the volume in 18 months, not today? Price the future state. A workflow that’s $40/month at launch and $500/month at scale is a problem you’re choosing to have later.
- Do the integrations exist natively? If the critical system is only supported by Zapier, the argument is over. Pay them.
Most of our contractor clients land on n8n because they end up with high-volume, logic-heavy workflows and we stay on a support retainer anyway. Most of our small professional-services clients land on Make, because they want to keep tinkering. A few land on Zapier and stay there happily, which is a perfectly good outcome.
The thing that matters more than the tool
We’ve seen excellent work in Zapier and unmaintainable disasters in n8n. The tool is maybe 20 percent of the outcome; the rest is whether someone thought carefully about the data model, wrote down what happens when a step fails, and gave the workflow an owner.
If you’re choosing between these three and it feels like a hard decision, that’s usually a sign you haven’t specified the workflow well enough yet. Specify it properly and the right tool tends to become obvious.