n8n vs Make vs Zapier: How the Billing Model Decides It

Almost every comparison of these three tools is a feature table, and feature tables are close to useless here because all three do the same job. They trigger on an event, move data between apps, and take an action. What actually separates them — and what will decide your bill — is how each one counts the work.

The one difference that decides it

Get this straight and the rest follows:

• Zapier bills per task. Every step that acts on data is a task. A ten-step Zap that runs once consumes ten tasks.
• Make bills per module. Similar in principle, materially cheaper per unit, and with better handling of loops and branching.
• n8n bills per workflow execution. The whole run counts once. A ten-step workflow and a two-step workflow cost the same.

So the cost gap between them is not a fixed percentage — it widens with the complexity of your workflows. Two simple automations, and the three are roughly comparable. Twelve-step workflows running continuously, and the same work costs several times more on Zapier than on n8n. At volume the difference commonly lands around five to eight times.

Complexity is free on n8n and expensive on Zapier. That is the whole comparison in one sentence.

Do the arithmetic before you choose

You need two numbers: how many times the workflow runs, and how many steps it has.

Take an order-processing flow with eight steps, running 500 times a day — about 15,000 runs a month. On Zapier that is roughly 120,000 tasks, which is well into the higher paid tiers and typically several hundred dollars a month. On n8n it is 15,000 executions, which sits inside modest plans or costs only the server on a self-hosted instance. Same automation, an order of magnitude apart, entirely because of how the meter runs.

Now change one variable: the same 15,000 runs but only two steps. The gap narrows sharply, and Zapier's ease of building may well be worth the difference.

When each one is genuinely the right answer

Choose Zapier when

Volume is low, workflows are short, and the person maintaining them is not technical. Zapier has the largest app library and by far the gentlest learning curve, and if a marketing manager can build and fix their own automations without booking developer time, that is worth real money. Paying more per task to avoid depending on someone else is a legitimate trade, not a mistake.

Choose Make when

You need branching, iteration and error handling that Zapier makes awkward, but you do not want to run infrastructure. Make is the reasonable middle: considerably cheaper than Zapier at equivalent volume, visual enough to be maintainable by a semi-technical team, and strong at the array and loop operations that real data work demands.

Choose n8n when

Any of these is true: volume is high, workflows are long, you want to self-host, or your data cannot legally pass through a third-party processor. Self-hosting turns a per-run bill into a fixed server cost, which for a busy workflow is the difference between hundreds of dollars a month and roughly the price of a small VPS. It also has real code nodes, so the awkward 5% of a workflow can be twenty lines of JavaScript instead of nine chained modules.

Choose none of them when

This option is missing from every comparison written by a company selling one of the three. If a workflow runs constantly, has no need of a visual editor, and is maintained by a developer anyway, a small script on a schedule is faster, cheaper and easier to test than any of them. Visual automation tools earn their cost by being editable by non-developers. Where nobody is going to edit them, you are paying a premium for a feature you will not use.

The costs the comparison tables leave out

• Self-hosting is not free. n8n on your own server means you own updates, backups, uptime and TLS. Call it a few hours a month, and add a managed database if the workflows matter.
• Polling burns runs. A workflow that checks for new rows every five minutes fires around 8,600 times a month whether or not anything happened. Webhooks fire only on real events, and switching from one to the other is often a bigger saving than switching platforms.
• Retries count. On per-task billing a flaky vendor is billed to you every time the step retries.
• Migration is real work. Moving thirty live Zaps to n8n is a project, not an afternoon. The saving has to clear that cost before it is a saving.

A short decision rule

1. Count your monthly runs and your average steps per run. Multiply them — that is your task count on per-task billing.
2. Under about 2,000 tasks a month, pick on ease of use. The price difference is not worth optimising.
3. Between roughly 2,000 and 50,000, Make is usually the best value per unit of capability.
4. Above that, or with any data-residency constraint, self-hosted n8n almost always wins on cost.
5. If a developer maintains it and no one else will ever open it, price a plain script before committing to any of them.

The mistake I see most often is not picking the wrong tool. It is picking on a demo and never doing step one, then discovering the billing model eighteen months later when the invoice has quietly quadrupled.

If you would rather not work through it yourself, that arithmetic is part of the discovery call — including the cases where the honest recommendation is to stay exactly where you are.