n8n vs Make vs Zapier in 2026: Which Should You Actually Build On?
We build client automations in all three. Here is how n8n, Make and Zapier compare on cost, reliability and WhatsApp lead follow up.
The short answer: Use Zapier if you need three or four simple app to app connections and nobody on your team wants to think about infrastructure. Use Make if you want visual branching, loops and cheap high volume runs without writing code. Use n8n if your automation involves AI agents, custom API calls, data you would rather keep on your own server, or thousands of runs a month where per task billing gets painful. Most businesses past a certain size end up on n8n for the core and keep one of the others for edge cases.
We build on all three. This is where each one genuinely wins, where each one hurts, and the parts that go wrong.
What is the actual difference between n8n, Make and Zapier?
All three do the same basic thing: something happens in one system, and they make something happen in another. The differences are in how much logic they let you express, how they charge, and how much control you keep.
Zapier is the most opinionated. A Zap is a trigger followed by a series of steps. It has the largest app directory by a wide margin, and the setup experience is the friendliest of the three. It also charges per task, where a task is roughly every action step that runs. Multi step Zaps burn tasks fast.
Make is a visual canvas. You draw modules and connect them, and you can branch, iterate over arrays, aggregate results and route conditionally without much friction. It charges per operation, and operations are cheaper than Zapier tasks, so heavy workflows are more affordable. The tradeoff is that complex Make scenarios become spaghetti quickly, and debugging someone else's canvas is genuinely unpleasant.
n8n is closer to a developer tool wearing a no code interface. Nodes on a canvas, but with a Code node that runs JavaScript or Python, native HTTP request nodes that talk to any API, real queue based execution, and the option to self host. It charges per workflow execution on cloud plans, not per step, which changes the economics completely: a workflow with forty nodes costs the same as one with three. It also has the strongest AI agent tooling of the three, with memory, tool calling and vector stores built in rather than bolted on.
Here is the honest side by side:
| Zapier | Make | n8n | |
|---|---|---|---|
| Billing model | Per task (per action step) | Per operation (per module run) | Per execution (any number of nodes) |
| Cost at high volume | Expensive | Moderate | Low, or free self hosted |
| Best at | Simple linear connections | Visual branching and loops | Custom APIs, AI agents, volume |
| Custom code | Restricted | JS in modules | Full JavaScript and Python |
| Self hosting | No | No | Yes |
| App directory | Largest (8,000+) | Large | Smaller, plus HTTP for anything |
| Learning curve | Lowest | Moderate | Steepest |
| AI agent support | Basic | Good | Strongest |
| Where it hurts | Cost at volume | Debugging complex scenarios | You own the maintenance |
Prices on all three change, so check the vendor pricing pages before you commit. The billing model is the durable thing to reason about, not this month's number.
Which one is cheapest once you are actually running volume?
Cheapest at ten runs a month and cheapest at ten thousand are different questions.
At low volume, all three are effectively free or nearly free, and you should pick on comfort. At real volume, the billing model dominates. Think about a single incoming property enquiry from Property Finder. A serious follow up workflow might: parse the lead, deduplicate against your CRM, look up the listing, pick a language, send a WhatsApp message, wait, check for a reply, classify the reply with an AI model, route hot leads to an agent, log everything, and schedule the next nudge if nothing came back.
Count the steps. That is fifteen to twenty five actions per lead, and some of them run more than once. On per task billing, one lead can consume twenty tasks. Five hundred leads a month becomes ten thousand tasks, which is nowhere near an entry level plan. On per execution billing, that same lead is one execution regardless of how many nodes fire.
That difference in unit is not a detail. It changes how you design. On per task pricing you are quietly incentivised to build fewer, cruder steps. On per execution pricing you build the workflow the process actually needs. Punishing complexity with per step billing pushes you to build worse automations, and worse automations lose leads.
The other cost nobody prices in is engineering time. Self hosted n8n is free in licence terms and not free in reality. Somebody has to run the server, handle upgrades, watch queue health and restore backups. If you do not have that person, pay for n8n Cloud or use Make. A broken automation nobody is monitoring is more expensive than any subscription. We publish what a build like this actually costs, including the running cost, because that second number is the one people forget.
When is Zapier still the right answer?
Often, and we recommend it without embarrassment in these cases:
- The workflow is five steps or fewer with no branching. New form submission to CRM, new invoice to Slack. Zapier will outlive your interest in the problem.
- The person who will maintain it is not technical and never will be. Non technical people genuinely understand Zaps. They rarely understand a 60 node n8n canvas.
- You need an integration that only Zapier has. Its catalogue is still the largest, especially for smaller SaaS tools.
- Volume is low and predictable, and you need it working this afternoon.
Zapier's real product is not automation, it is not having to think. For a founder wiring a form to a spreadsheet to Slack, that is worth paying for.
What does not work is using Zapier as a workflow engine for anything with real branching or memory. You end up chaining Zaps together, adding a Google Sheet as a fake database, and discovering three weeks later that leads have been silently dropping because a step failed and nothing alerted you. At that point you have built a fragile version of n8n at higher cost.
When does Make make sense?
Make sits in the middle, and the middle is a legitimate place to be:
- You need branching, routers and iterators but not custom code.
- You want to see the data flow. Its visual builder genuinely is the clearest of the three for debugging a moderately complex scenario.
- You are processing arrays and collections, which Make handles more gracefully than Zapier.
- Cost matters, but not enough to self host.
Where it hurts: the visual model gets unwieldy past a certain complexity, handing a large scenario to someone else is painful, and you are still renting someone else's infrastructure with your data flowing through it. If you already run Make and it works, we would not migrate you for the sake of it.
When is n8n worth the extra work?
- Volume is high. Per execution pricing, or self hosted with no per run cost at all.
- Data cannot leave your infrastructure. Healthcare, finance, legal, or any client whose contract says so. This is often not a preference but a requirement, and it eliminates the other two outright.
- You need code. n8n lets you drop a JavaScript or Python node in the middle of a visual workflow. No workaround, no external function call, just code where you need it.
- You are building AI agents. n8n's agent tooling, with LangChain nodes, memory, tool calling and vector stores, is well ahead of the others for anything beyond "call an LLM and return the text".
- The workflow is genuinely complex. Sub workflows, error branches, retries, queues.
Where it hurts: someone has to run it. Self hosting means a server, updates, backups and monitoring. n8n Cloud removes that but gives back some of the cost advantage. And the learning curve is real, because it assumes you understand APIs, JSON and data shapes.
Which platform handles WhatsApp lead follow up best?
WhatsApp is where the platform choice stops being academic.
Portal leads from Bayut, Property Finder and Dubizzle do not arrive in a tidy queue. They arrive as email notifications, webhooks, CRM records or all three, in several formats, at every hour of the day and night, often from the same buyer enquiring on four listings. Buyers routinely message several agencies at once, and the Harvard Business Review study "The Short Life of Online Sales Leads" found firms that responded within an hour were roughly seven times more likely to qualify a lead than those that waited even slightly longer. Speed is the product. We wrote more about that in our post on why lead response time decides Dubai property deals.
A real WhatsApp follow up system therefore needs four things:
- Ugly input handling. Parsing inconsistent email bodies and webhook payloads. This means custom code, not a dropdown.
- Conversation state. Knowing whether this person already replied, what they asked, and which agent owns them.
- Reply understanding. Telling "not interested" apart from "send me the floor plan" apart from "call me tomorrow at 4".
- Timed sequences. Nudges over days, that stop the moment a human takes over.
Zapier can do a one way notification. It struggles with state and multi day sequences without stacking on extra tools. Make can do the whole thing, and we have built working WhatsApp flows in Make, but state management gets awkward and the scenario grows hard to hand over. n8n handles all four cleanly: the HTTP node talks straight to the WhatsApp Cloud API, the Code node normalises whatever the portals throw at you, the AI agent nodes classify replies with memory attached, and Wait nodes plus queue mode handle multi day sequences without a cron hack.
We built our first lead response and AI agent systems for visa and immigration companies, where the shape of the problem is identical: high enquiry volume, WhatsApp first buyers, and a small team that cannot answer at 2am. That is the engine behind our Dubai real estate WhatsApp follow up service, and you can see the build patterns in our case studies.
Is n8n actually open source?
n8n is source available under the Sustainable Use License, not open source in the OSI sense. In plain terms: you can self host it, use it internally, and modify it freely. You cannot resell it as a hosted product competing with n8n.
For the overwhelming majority of businesses and agencies this is irrelevant, because internal use and client work are both fine. It only bites if your business model is "we sell hosted n8n". Worth knowing, rarely worth worrying about.
How do you migrate without breaking what already works?
The mistake is turning the old system off first. Do this instead:
| Step | What you do | Why |
|---|---|---|
| 1 | Write down every workflow you actually rely on | Most accounts have half broken Zaps nobody remembers building |
| 2 | Rebuild the highest volume one first | Biggest cost saving, fastest proof |
| 3 | Run both in parallel for a week | You compare outputs instead of guessing |
| 4 | Add failure alerts before cutover | Silent failure is the real risk, not migration |
| 5 | Retire the old workflow, keep it disabled for a month | Cheap insurance |
Two extra rules. Log every run somewhere you can query, because "did the lead get a message?" should never be a guess. And decide up front who owns the system after launch. Automation is not a project you finish: portals change formats, WhatsApp templates get rejected, APIs deprecate. Either you have someone maintaining it or you buy that as part of the service.
How to actually choose
Work down this list and stop at the first "yes":
- Must the data stay on your own infrastructure? Then n8n, self hosted. Nothing else qualifies.
- Will this run more than a few thousand times a month? Then n8n. The pricing model wins and keeps winning.
- Do you need custom code, or AI agents with tool calling? Then n8n.
- Do you need branching and array handling, but no code? Then Make.
- Is it under five steps and maintained by a non technical person? Then Zapier.
- Does only one platform have the integration you need? Then that one. Availability beats elegance.
What we do in practice
For client work we default to n8n, usually self hosted, for the core operational workflows: lead intake, CRM sync, AI agents, anything touching sensitive data or running at volume. That is where the pricing model, the code escape hatch and the data control all compound.
We keep Zapier or Make for the edges: a one off integration only they support, or a workflow a client's own non technical team needs to edit without calling us. Handing someone a tool they will actually maintain beats handing them a better tool they will not touch.
If your automation is a straight line and low volume, Zapier. If it is branchy and visual and mid volume, Make. If it involves AI, custom APIs, WhatsApp conversations or real volume, n8n, and pay for cloud hosting unless you have an engineer. Choose on the shape of the work, not on which logo you have heard of. The mistake is treating this as a religious question: it is a per workflow decision, and mixing is normal. More on who we are and how we work.
FAQ
Is n8n really cheaper than Zapier?
At meaningful volume, substantially, because the pricing units differ. Zapier bills per task (roughly per action), so a six step workflow costs six times a one step one on every run. n8n bills per execution, so workflow complexity is free, and self hosted there is no per run cost at all. At very low volume the difference is negligible and Zapier's free tier may be cheaper in practice.
Is Make cheaper than Zapier?
Generally yes for the same workflow, because Make charges per operation and its operations are cheaper than Zapier tasks, so multi step scenarios cost less. Its router also lets one scenario do work that would need several separate Zaps. n8n can be cheaper again at high volume because it bills per execution rather than per step. Check current pricing on each vendor's site before deciding, since all three change tiers regularly.
Is n8n open source, and is it free?
It is source available under the Sustainable Use License, not OSI open source. You can self host, modify and use it commercially, including for client work, and the community edition is free to run on your own server indefinitely. What it is not is free in effort: you handle updates, backups, monitoring and scaling yourself. n8n also sells a managed cloud plan, which is what we recommend for most businesses without technical staff.
Can n8n replace Zapier completely?
For most workflows, yes. The gap is integration catalogue, since Zapier supports more individual SaaS tools out of the box. n8n covers this with a generic HTTP request node, which handles any tool with an API but requires you to read the API docs rather than click a pre built connector.
Which platform is best for AI agents?
n8n, clearly. It has native agent nodes with memory, tool calling and vector store support, plus a code node for anything the nodes do not cover, so you can build an agent that reads a WhatsApp reply, decides what it means and picks the next action. Zapier and Make both offer AI steps, but they are better suited to single calls like summarising text than to agents that hold a conversation.
Can Zapier send WhatsApp messages?
Yes, through third party WhatsApp Business API providers and their Zapier integrations, so simple one way notifications are straightforward. Where Zapier struggles is two way conversation: tracking replies, understanding what a buyer said, and running multi day follow up sequences that stop when a human steps in. For that we use n8n talking directly to the WhatsApp Cloud API.
Do I need a developer to use n8n?
Not to use it, but you will get further with one. The visual builder is usable without code, but n8n assumes familiarity with APIs, JSON and data structures in a way Zapier deliberately does not. Self hosting additionally needs someone comfortable running a server.
Can I migrate from Zapier to n8n?
Yes, though not automatically. There is no import tool, so workflows are rebuilt rather than converted. In practice this is usually an improvement, because Zaps tend to carry workarounds for limitations n8n does not have, and rebuilding lets you collapse several Zaps into one workflow. Run both in parallel for a week before you switch anything off.