n8n vs Make vs Zapier: which one your workflow should actually live in.
We build on all three. The choice is decided by who maintains it, where the data may sit, and what the workflow costs at your volume.
These three tools overlap enough that most workflows could be built in any of them, which is why comparison articles that declare a winner are not much use. The decision is made by constraints outside the tool: who edits it after handover, whether the data can leave your infrastructure, and how the pricing model behaves at your volume.
Coastline Logistics runs on n8n. Not because it is the best product in the abstract, but because they wanted to own and edit the workflow themselves and preferred it running in their own infrastructure. That is a reason you can check against your own situation.
Everything below is the current shape of each platform as we build on them. Pricing models change, so check each vendor's page for today's numbers rather than trusting a figure in an article.
Side by side
Compiled from our own builds on all three platforms. Pricing models are described by shape rather than by price, because vendors change the numbers; check their pricing pages before budgeting.
When each one is the right answer
Choose Zapier when the workflow is simple and the team is not technical
If the flow is a handful of steps between two popular apps and the person maintaining it is in marketing or operations rather than engineering, Zapier is the right answer and we will tell you so. The catalogue is the largest, the mental model is the simplest, and someone else in your company can pick it up without training. The cost per task stops being attractive at high volume, but plenty of workflows never reach that volume, and paying a little more for something your team can edit unaided is usually a good trade.
Choose Make when the logic branches and the volume is real
Make handles routers, filters and multi-path scenarios more comfortably than the others, and its per-operation pricing is kinder at volume than per-task billing. If your workflow has genuine decision points and runs thousands of times a month, this is often the cheapest correct answer, and its visual model keeps a complex scenario legible to a non-engineer.
Choose n8n when the data must stay in your infrastructure, or the logic is really code
Self-hosting is the deciding factor most often: regulated data, a security review that will not accept a third-party cloud, or a customer contract that forbids it. The second reason is code. If half your workflow is a matching algorithm rather than a sequence of app calls, writing it in a JavaScript or Python node beats assembling it from twenty visual steps. Coastline chose it for both reasons and now edits the workflow themselves.
Pricing shape matters more than price
Per-task billing charges for each action, so a workflow with twelve steps costs twelve units per run. Per-operation billing is similar in structure but usually cheaper per unit at volume. Self-hosting moves the cost to infrastructure and maintenance, which is close to fixed as volume grows.
The practical consequence is that a workflow which is affordable at 500 runs a month can be uncomfortable at 50,000. Before choosing, multiply your realistic monthly volume by the number of steps and check it against each vendor's current pricing, because that arithmetic decides more of these debates than any feature.
The real question is who edits it in nine months
Every automation gets a change request eventually: a new supplier, a changed field, an extra approval. The cost of that change is dominated by whether the person who needs it can make it, or whether it joins an engineering backlog.
So we choose partly on your team. A technical operations lead who is comfortable in code gets a different recommendation from a two-person marketing team. Coastline's choice of n8n was made on exactly this basis, and it is why they still run the workflow without us.
Where none of the three is the right answer
When the logic is the product rather than the plumbing, a workflow tool becomes a liability. A matching engine with hundreds of rules, anything needing real transaction handling, or a process where the automation is a core competitive asset should be plain code in your own repository.
Coastline's build is a hybrid for this reason: n8n orchestrates, and the matching logic that actually decides things is Python. That split keeps the visual workflow readable and the hard part testable, and it is our default recommendation for anything with real logic in it.
Error handling is where builds are separated
All three tools can retry. What matters is whether your workflow is safe to retry, which is a design property rather than a platform feature. Runs we build are idempotent and checkpointed, so a failure resumes from the step rather than the beginning and never double-sends a purchase order.
The second half is where a failure goes. An error that lands in a vendor log nobody reads is an outage waiting to be discovered by a customer. Ours post into a channel with the context attached, which is how Coastline's team clears exceptions in the morning instead of finding them in a report.
How we decide, in one paragraph
If the data cannot leave your infrastructure, it is n8n. If the workflow has complex branching at high volume, it is usually Make. If the team is non-technical and the connectors exist, it is Zapier. If the logic is the interesting part, it is code with one of the three orchestrating around it.
That decision is made in the audit week with your volumes and your team in front of us, and it is written down with the reasoning, so a future engineer can see why rather than guessing.
The work behind the numbers
Keep reading
Questions people ask on this one
n8n, for two reasons that may not apply to you: much of our work involves data that clients prefer to keep in their own infrastructure, and many builds have real logic that belongs in code. For simpler client workflows we build on Zapier or Make without hesitation.
Yes, and it is usually a rebuild rather than a conversion, because the platforms model steps differently. Budget it as a small project rather than an export. The upside is that a migration is a good moment to fix the error handling that was probably never designed.
It is real work: a container to run, updates to apply, backups, monitoring, and someone accountable when it stops. If your team already runs infrastructure it is minor. If it does not, the honest comparison is Make or Zapier plus their fees against self-hosting plus the operational burden.
They are genuinely useful for simple steps such as classification and drafting. For anything where accuracy needs measuring, we put the model behind our own layer with an evaluation set, because a prompt inside a workflow node is difficult to test and easy to change by accident.
Not always. If a workflow runs constantly and carries real logic, plain code in your repository is often simpler and cheaper to own. Workflow tools earn their place when non-engineers need to see and edit the flow, which is a real and common requirement.
A pilot starts at $4,000 and is usually live in about three weeks. A full flow like Coastline's, with matching logic, exception routing and reporting, runs $15,000 to $50,000. The platform choice affects your running costs far more than it affects the build price.
Want a second opinion before you decide?
Thirty minutes, no pitch deck. If the honest answer is the other column, we will say so on the call, and you will leave with the reasoning written down.