Make, n8n or Zapier: the comparison nobody does properly

The three platforms do not bill the same thing. One counts every successful action, one counts every module step, one counts a whole run regardless of length. Comparing their headline prices is meaningless until you translate your actual workload into each unit. That translation is the first thing we do.

Describe your workflow →

Everything in writing, no callsReply within 24 working hoursSelf-hosting on a private server in Europe when it fits

Three price lists that cannot be compared as published

Teams pick an automation platform by looking at monthly prices side by side, then discover the bill six months later bears no relation to what they expected. The reason is structural rather than sneaky: each vendor bills a different unit of work, so the same workflow can cost wildly different amounts depending on how it is shaped. A workflow with many small steps and one with a few heavy ones sit at opposite ends on one platform and are identical on another.

1 task

Zapier bills each successful action in a Zap

1 credit

Make bills each module action inside a scenario

1 execution

n8n bills one full run, whatever the step count

How we pick, and why the answer is not always the same tool

Translate your real workload into all three units

We take the workflows you actually run, count them the way each vendor counts, and put the three numbers next to each other. A ten-step workflow running a thousand times a month is ten thousand units on one platform and one thousand on another. This is arithmetic, not opinion, and it usually settles the question before anyone argues about features.

Separate what must be reliable from what can fail quietly

A workflow that posts to a channel can fail for a day without much harm. A workflow that creates invoices cannot. We split them, because the reliable ones justify monitoring and retry logic while the rest do not, and treating everything as critical is how automation budgets get wasted.

Know when to stop assembling and start writing code

Connector platforms are excellent up to a point and expensive past it. When a workflow needs branching that the interface cannot express, or when the unit count makes the monthly bill exceed what a small service would cost to build and run, assembling stops being the cheap option. We say so rather than selling more connectors.

Make failure visible, because silence is the real risk

The dangerous automation is not the one that breaks loudly. It is the one that stopped three weeks ago and nobody noticed, while everyone kept assuming the records were being created. Every workflow we build reports its own failure somewhere a human actually looks.

What we commit to

< 24h

Reply to your brief

In writing

Scope settled before we start

Always

Workflows documented and exportable

None

Calls, video meetings, travel

Three scopes, quoted once we have seen the workflows

Platform review

On quote

Your workload translated into all three billing units
Side by side monthly cost at real volume
Written recommendation with the reasoning
No build commitment

Describe your workflow →

Recommended

Build

On quote

Workflows built on the platform the numbers chose
Critical paths separated from the rest
Failure reporting where someone will see it
Written documentation handed over

Describe your workflow →

Build and self-host

On quote

Everything in the build scope
n8n self-hosted on a private server in Europe
Backups with a restore tested before handover
You keep the server, the data and the workflows

Describe your workflow →

Why the three price lists cannot be read side by side

The comparison articles published on this subject almost all make the same mistake: they put three monthly prices in a table as though those prices measured the same thing. They do not. Here is what each one counts, what that does to a real workload, and where the reasoning stops applying.

The same workflow, three completely different bills

Take a workflow that reads a form submission, checks a record, updates a spreadsheet, sends an email and posts a notification. That is five steps. On a platform that bills each successful action, running it a thousand times a month consumes five thousand units. On a platform that bills each module action inside a scenario, the count is similar. On a platform that bills one execution per run regardless of length, the same workload consumes one thousand. The ratio here is five to one, and it comes purely from how the vendor counts, not from anything about the work. Now imagine that workflow grows to fifteen steps, as they always do. The ratio becomes fifteen to one, and a decision that looked marginal at signup becomes the dominant cost line. This is why we refuse to recommend a platform before counting.

What self-hosting actually moves, and what it does not

Self-hosting changes who carries the risk, not just who pays the bill. You stop paying per unit and start paying for a server, which is predictable, and for updates, backups and incident response, which are not free even when they are unpaid. The version we recommend is honest about that: the server cost goes in the quote, the backup routine is built and its restore tested before handover, and the documentation is written so somebody other than us can take over. What we will not claim is that self-hosting is simply cheaper. It is cheaper at volume, more expensive in attention, and the crossover depends on numbers we can only calculate once we see your workflows.

The failure mode nobody plans for

Almost every automation estate we inherit has the same defect, and it is not a broken workflow. It is a workflow that stopped weeks ago while everyone continued to assume it was running. Records were not created, notifications were not sent, and the gap surfaced through a customer complaint rather than an alert. Connector platforms do report errors, but into an interface that nobody opens between incidents. So the rule we apply is simple: a failure has to arrive where a human already looks, which in practice means an inbox or a working channel. It costs almost nothing to build in at the start and it is the difference between an automation you can trust and one you merely hope is running.

01Make, n8n or Zapier: what actually decides it?

The shape of your workload, translated into each vendor's unit. Zapier bills each successful action in a Zap, Make bills each module action inside a scenario, and n8n bills a full execution regardless of how many steps it contains. So a workflow with many small steps is punished on the first two and neutral on the third, while a low volume of simple workflows can be cheapest on the platform with the friendliest free tier. Features matter too, but they rarely override an arithmetic gap of this size.

02Is self-hosted n8n really cheaper than Make?

Sometimes, and less often than the comparison articles suggest. Self-hosting removes the per-unit bill and replaces it with a server, updates, backups and someone responsible when it stops at two in the morning. At high volume that trade is clearly worth it. At low volume you are paying with attention rather than money, which is not obviously a saving. We put both columns down and let the numbers decide.

03How do we find out an automation has stopped?

Only if it was built to tell you. This is the single most common defect we find when we take over someone else's automations: they fail silently, and the failure is discovered weeks later through its consequences rather than through an alert. Every workflow should report its own failure into a place a human already looks, whether that is an inbox or a channel. A dashboard nobody opens does not count.

04When does custom development cost less than assembling connectors?

When the monthly unit bill approaches what a small dedicated service would cost to build and run, or when the logic outgrows what the interface can express. There is no fixed threshold, but the signal is recognisable: workflows that have grown to twenty or thirty steps with branches inside branches, and a bill that climbs every month. At that point the connector platform has become the expensive way to do it, and we will tell you.

05How does a project run, and when should you not write to us?

Everything is handled in writing, by email, with a reply within 24 working hours. Do not write to us if your project requires calls, video meetings or on-site presence, because none of those are in scope. Do not write to us either if you need someone to operate the automations day to day: we build, document and hand over, and somebody on your side has to own them afterwards.

What else we build

Hire Full-Stack Developers Who Actually Ship Website Redesign Agency API Development Agency Moving off Airtable onto PostgreSQL, once the numbers say it pays

Related services

Marketing website Website redesign Web application

See all our services

4.9/5 sur 35 avis clientsRead what our clients say

Send us the workflows, we send back the three numbers

Describe what you automate, roughly how many steps each workflow has and how often it runs. You get back the same workload costed in all three billing units, with a written recommendation and the reasoning behind it, within 24 working hours.

Get the comparison →