The short answer first: Zapier if a simple process runs rarely and you want to click it together yourself. Make if you think visually and the volumes stay modest. n8n if it runs often, the data is sensitive, or the logic goes beyond if-then.
And a fourth answer that appears in none of these comparisons: sometimes the right tool isn't an automation tool at all, but a small piece of custom software. How to recognise that is further down, and it is the most useful part of this text.
My cards on the table: I build with n8n or with small custom applications. I don't run Make or Zapier. That doesn't make them worse, it means that I recommend them for the cases where they win and then don't get the project. Those cases are all in here.
What the three actually are
All three do the same basic job: listen for an event, fetch data, reshape it and write it somewhere else. What differs is where they run, how they bill, and how far you get before the tool starts slowing you down.
- Zapier is the oldest and has by far the largest catalogue of ready-made connections. Cloud only, a US provider, very shallow to operate. If a niche app is connected anywhere at all, it is connected here.
- Make is the visual one: you see your process as a diagram rather than a list, which genuinely helps once there are branches. Cloud, with a data centre in the EU if you pick one, and usually cheaper per unit than Zapier.
- n8n is open (fair-code, to be precise) and runs as a cloud service or on your own server. It has a code node for the cases where ready-made blocks aren't enough, and it bills on a different basis than the other two.
The real difference is how they count
Almost every comparison lines up features. In practice something else decides whether an automation still makes sense a year later: what gets counted. The three count different things.
Zapier counts tasks
Every executed step is a task. A process with eight steps burns eight tasks per run. Clean the process up by adding one more step, and you pay for it.
Make counts operations
The same logic in principle, but considerably cheaper per unit. In exchange, helper steps like filtering and reshaping count too, and a real process has more of those than you'd think.
n8n counts runs
One complete run is one execution, whether it consists of three steps or thirty. On your own server nothing is counted at all, and there you pay for the server instead.
The consequence only shows in an example. Take a process with eight steps that runs 500 times a month, which is a perfectly ordinary size for “enquiry arrives, gets classified, recorded and answered”. On Zapier and Make that is 4,000 units a month. On n8n it is 500. On n8n on your own server it is zero, plus the server you were paying for anyway.
I deliberately name no concrete tariffs here: all three change their pricing regularly, and a figure in today's article is a wrong figure a year from now. The counting principle rarely changes, and it is the part that dominates your bill.
Below roughly a hundred runs a month the billing model is irrelevant, so take whichever suits you. Above a few thousand steps a month it becomes the largest line item of the whole automation, every single month.
Where your data sits while this happens
Every automation moves data. For an appointment confirmation that is harmless. As soon as job applications, personnel files, health data or client information pass through, it is data processing with everything that comes with it: a contract, a record, and a look at where the provider sits and who it passes things on to.
Make lets you choose a data centre in the EU, Zapier is a US service, and both are workable for the vast majority of cases once the contracts are in place. n8n has an argument here the others structurally cannot have: on your own server, the content of a run never leaves your infrastructure. In some industries that isn't an advantage but the condition under which any of this happens at all.
The honest price for it: your own server needs running. Updates, backups, monitoring, someone who notices when nothing moves overnight. It isn't a big line item, but it isn't one to leave unsaid either, because it is exactly why the cloud option stays right for a lot of people.
When Zapier or Make clearly win
There are three situations in which I advise against n8n, even though it is what I work with.
The app in question is exotic
Zapier's catalogue is the largest by a wide margin. If your industry software has a ready-made connection only there, the discussion is over. Anything else would mean building the interface yourself, and that costs more than the subscription.
It should stay small and nobody is technical
Three steps, twenty runs a month, built by someone in the office over an afternoon. Any consulting conversation costs more than the thing itself, and Zapier is made for exactly this.
The team wants to see the process
Make shows the process as a picture, and that is worth more than it sounds. When several people without a technical background need to understand what happens, the visual representation beats any technical superiority.
The common thread: the smaller and rarer it is, the less the tool matters. The differences only become relevant with volume, sensitivity and lifespan.
How to tell no automation tool fits at all
This is the part comparison articles never carry, because they come from someone selling one of the three. There is a point at which an automation tool is the expensive answer, and four fairly reliable signs of it.
- Your process has more than about 25 nodes. Past that size nobody grasps it at a glance any more, and every change becomes a hunt. What started as a diagram has long been a program, only one without version control and without tests.
- Half the steps only reshape data. When five nodes sit between two real actions just renaming fields and sorting lists, you are fighting the tool. Ten lines of code would be more readable and cheaper.
- Somebody has to enter something or look at it. Automation tools have no interface. As soon as a human is meant to set a status, work through a list or make a decision, you end up building crutches out of spreadsheets and forms.
- There is state over time. “This enquiry has been waiting three days for a reply” is not an automation, it is a database with a view in front of it. Rebuilding that in an automation tool means building a database, only worse.
If one of those applies, switching tools won't help. The process has outgrown the tool, and the honest answer is a small custom application.
The small custom app as a fourth option
“Custom application” sounds like a big project, but here it is the opposite: one process, one group of users, one screen. A page listing the open items, with two buttons next to them. Everything else keeps running as automation, often in n8n, and the app is only the part a human looks at.
That is usually cheaper than trying to rebuild the same thing inside an automation tool, and not only to run but to build, because you stop working against the tool. The full arithmetic is in buy or build, and the principle is identical, just one level down.
An automation tool connects systems. The moment a human is supposed to see or decide something in the middle, you don't need a better automation tool, you need an interface.
How I decide this in a first conversation
Four questions, and after them the answer is almost always settled. You can work through them yourself, and you don't need me for it.
How often does it run?
Under a hundred runs a month: take whatever stands up fastest. Over a thousand: work through the billing model before you build anything.
What passes through it?
Public or harmless data is uncritical. Personnel, health or client data shifts the question from “which tool” to “where does it run”.
How much logic is in there?
A straight chain is within reach of all three. Branches, loops and exceptions are the point where click-together interfaces start to hurt.
Does anyone need to look inside?
If a human regularly sets a status or works through a list, the answer is no longer the automation tool but an interface on top of it.
Switch or stay
If something is already running and doing its job, switching is almost always the wrong idea. Rebuilding a live automation costs time, adds no new value and produces a stretch of errors that were gone before. The appeal of a better tool is not a reason.
Three reasons genuinely justify a switch: the monthly bill is visibly larger than the benefit. Data suddenly passes through that isn't allowed to sit there. Or the process has grown so much that nobody wants to change it any more. In all three cases you don't move everything at once, only the one process that hurts.
And if nothing is running at your end yet, the tool question is the second one anyway. The first is which process to automate first, a decision with far more consequence than the one between n8n, Make and Zapier, and it costs nothing but an hour of thinking.
- Zapier counts steps, Make counts operations, n8n counts whole runs. At high volumes that difference dominates the bill.
- Below a hundred runs a month the tool barely matters. Volume, data protection and lifespan are what create the difference.
- Zapier wins on exotic apps and small self-built processes, Make on visual work in a team.
- n8n can run on your own server. With sensitive data that is often not an advantage but the condition, at the cost of running it.
- More than 25 nodes, lots of pure reshaping steps, a needed interface or state over time: then no automation tool is the right tool.
- What runs and does its job doesn't get switched. Only the bill, data protection or unmaintainability are real reasons.
Common questions
Is n8n free?
On your own server the software itself costs nothing, but the server and running it do. There is also a cloud option with a subscription. And n8n is open in the fair-code sense rather than the classic open-source one: the code is readable and self-hostable, but the licence restricts reselling it as a service of your own. For use inside your own company that makes no difference.
Can I build this myself or do I need someone?
Most people manage the first one or two processes themselves, especially in Zapier. The hard part isn't the building, it's what comes after: what happens on an error, what happens with duplicates, who notices when it quietly stops. That is where help pays off, rather than at the first box.
What about credentials and passwords?
All three have a credential store that keeps keys separate from the process. What you shouldn't do anyway: paste a key into an ordinary text field to save time. It then shows up in every export and every log.
Is moving from Zapier to n8n worth it for the cost?
Only if the bill visibly hurts. A rebuild costs working time and produces new errors for a while. As a rule of thumb: if the rebuild pays for itself in saved fees within a year it's worth it, and otherwise it isn't.
And what about AI inside these tools?
All three can now call language models, and for a single step such as classifying a text, summarising it or drafting it that is exactly right. It is a different matter when a system is supposed to decide for itself what to do next. Where that line runs is in AI agent or automation.
