Decision matrix
n8n, Make, Zapier or code: weigh it for your flows
Set how much each criterion matters for the automations you plan. Billing and licence notes in the cells come from the vendors’ own pages, listed under Sources.
1 · Set what matters to you
2 · Where your weights lean
- n8nGood fit
- MakeGood fit
- ZapierGood fit
- Custom codeGood fit
Close call between n8n and Make. When the matrix is this close, the discovery questions below decide it, not the scores.
3 · The matrix, cell by cell
| Criterion · your weight | n8n | Make | Zapier | Custom code |
|---|---|---|---|---|
| Your team builds and edits flowsWeight: Medium | Good fit A visual editor, but expressions and self-hosting suit technical users best. | Strong fit A visual scenario builder designed for non-developers. | Strong fit The simplest editor of the four, built for business users. | Poor fit Only developers can change it. |
| Branching, loops and error pathsWeight: Medium | Strong fit Strong: branches, loops, sub-workflows and a dedicated error workflow. | Good fit Routers, filters and error handlers such as Retry, Skip and Rollback. | Partial fit Filters and Paths cover simple branching; complex logic gets awkward. | Strong fit Anything the language can express, including complex retries and state. |
| Data stays on your own serversWeight: Low | Strong fit Self-host on your own server, or use n8n Cloud. | Poor fit Scenarios run in Make’s cloud, so data passes through it. | Poor fit Zaps run in Zapier’s cloud, so data passes through it. | Strong fit Runs wherever you deploy it, including your own servers. |
| Cost stays low at high volumeWeight: Medium | Strong fit Billed per workflow execution regardless of its steps; self-hosting moves the cost to your server. | Partial fit Paid in credits; every module run on every bundle is an operation, so bundles multiply the count. | Partial fit Billed per task, meaning a successful action; triggers, filters and errored steps do not count. | Strong fit Pay for compute only; the real cost is developer time to build and maintain. |
| Reacts to events quicklyWeight: Low | Strong fit Webhook triggers start a run as the request arrives. | Good fit Instant triggers and webhooks where the app supports them; scheduled checks otherwise. | Good fit Polling triggers check every 1 to 15 minutes depending on plan; REST hook triggers run in near real time. | Strong fit As fast as your infrastructure, with queues and webhooks under your control. |
| Ready-made connectorsWeight: Medium | Good fit A broad node library, plus a generic HTTP node for anything else. | Strong fit A large app library, plus HTTP and webhook modules. | Strong fit A broad catalogue of ready-made app connections. | Poor fit Every integration is written against the app’s API. |
| Version control, tests and reviewWeight: Low | Good fit Workflows export as JSON you can keep in a repository and review. | Partial fit Scenario blueprints export, but review and testing happen in the editor. | Partial fit Changes are made in the editor; code-style review and automated tests are limited. | Strong fit Full version control, automated tests and code review. |
| Upkeep without a developerWeight: Medium | Partial fit Self-hosting needs someone to run updates, backups and the database. | Strong fit Make runs the platform; someone still owns the scenarios and their errors. | Strong fit Zapier runs everything: the least upkeep of the four. | Poor fit Needs a developer for every change and to keep dependencies current. |
| Licence fits how you will use itWeight: Low | Partial fit Sustainable Use License: fine for your own internal business use; letting your customers build workflows needs a separate agreement. | Good fit A standard SaaS subscription; nothing extra to license for internal use. | Good fit A standard SaaS subscription for internal use. | Strong fit Your own code, under whatever licence you choose. |
We build with all four, which is why every rating states its reason: check them against the vendors’ docs under Sources. Plans and terms change, so re-read them before you commit.
What you are really choosing
All four can move data between your tools, call an AI model and send a message when something happens. The editor is the least important difference. What separates them is what you are billed for, where the flows run and therefore where your data goes, what the licence lets you do, and who on your side can safely change a flow at short notice.
The billing unit decides the cost curve
n8n prices its plans on workflow executions, where one execution is a single run of the whole workflow no matter how many steps it has or how much data it moves. Self-hosting replaces that with the cost of running your own server.
Make counts operations and bills in credits. An operation is a module run that processes or checks data, and modules process each bundle separately, so bundles from early modules multiply the operations in every later one. A trigger counts once per check, however many bundles it returns.
Zapier counts tasks. A task is a successful action; triggers, filters, paths, steps that error and several built-in utilities do not use tasks. On plans without pay-per-task billing, reaching the limit holds new Zap runs until the billing cycle resets.
| Tool | What gets counted | Count for this check |
|---|---|---|
| n8n | Workflow executions | One, if a single run handles the batch; ten, if each order triggers its own run |
| Make | Operations, paid in credits | One for the trigger check, plus ten for each of the two write modules: twenty-one |
| Zapier | Tasks (successful actions) | Each new order runs the Zap with two actions: twenty |
| Custom code | Compute time and requests | Whatever your infrastructure bills; usually small next to developer time |
The pattern matters more than the totals. Per-step billing grows with the length of your flows; per-run billing grows with the number of runs; code shifts the cost into people. Before you choose, estimate a busy month of real runs and price it under each unit.
Where it runs, and where your data goes
Make and Zapier run your flows in their own cloud, so every record a flow touches passes through it, and run history may keep a copy of the payloads for a while. That is acceptable for most business data once you have read the retention settings. When it is not, for example with health or payment details, the options are self-hosted n8n or custom code on infrastructure you control, with the extra upkeep that brings.
The licence question people miss
n8n’s self-hosted edition is published under its Sustainable Use License, which lets you use and modify it for your own internal business purposes or for non-commercial and personal use, and only distribute it free of charge for non-commercial purposes. n8n’s licence FAQ says hiring someone to build workflows for you is fine, while making n8n available to your customers so they can connect their accounts and build their own workflows is not internal use and needs a separate agreement. If automation is part of a product you sell, settle that before anyone builds.
When custom code wins
- Volume is high enough that per-step or per-run billing outgrows the cost of a small service.
- The flow keeps state across many events, such as a long approval chain or a reconciliation.
- Every change must pass code review and automated tests before it runs.
- The systems involved have unusual APIs, or none of the tools has a connector worth trusting.
- You already run services and have developers who will own one more.
Mixing tools without losing track
Using more than one is common and sensible: Zapier or Make for small glue flows a business team owns, n8n or code for the core pipelines that carry customer data or money. The rule that keeps it maintainable is one tool per pipeline. A pipeline that hops from one platform to another is hard to debug, harder to make idempotent and nobody’s responsibility when it fails.
The questions we ask in discovery
- Which flows do you run today, in which tools, and which ones fail most often?
- Roughly how many runs does each flow see in a busy month, and how many steps does each run take?
- Which data in these flows is personal, financial or health-related?
- Who will change a flow when a field is renamed or a new branch is needed, and how quickly?
- Do you already pay for one of these tools, and does anyone on the team know it well?
- Will any of this be offered to your own customers as part of a product?
- What should happen, and who should be told, when a run fails at night?
How we decide
- List each pipeline separately; the right tool can differ between them.
- Rule out options on hard constraints first: where data may go, licence terms, who must maintain it.
- Price the survivors on a busy month of realistic runs, using each vendor’s own counting rules.
- Prefer the tool your team already knows when the numbers are close, because upkeep outlasts the build.
- Write the choice and the reason into the proposal for each pipeline, so it can be revisited when volume changes.
When MiniAI Labs is the wrong choice
If your flows are a handful of simple app-to-app steps and someone on your team enjoys building them, configure Zapier or Make yourselves. Paying us to build them is poor value, and we will say so.
If you want to embed an automation builder in a product your customers use, start with the vendors’ embedding terms; that is a licensing decision before it is an engineering one.
If you need people watching your automations around the clock with response times written into the contract, a managed operations provider will serve you better than a founder-led studio.
Limits of this comparison
- Vendor billing units, plan limits and licences change; the facts here hold as of the access dates in the sources, and we quote no prices.
- The worked example simplifies real runs: filters, errors, retries and deduplication all change the counts.
- Ratings are our judgement for typical business flows, not benchmark results.
- We build with all four tools, so read the reasons in each cell rather than the ratings alone.
Sources
- n8n Plans and Pricing (opens in a new tab) · n8n · accessed
- Community license (Sustainable Use License) (opens in a new tab) · n8n Docs · accessed
- Handle errors gracefully (opens in a new tab) · n8n Docs · accessed
- Operations (opens in a new tab) · Make Help Center · accessed
- Error handlers (opens in a new tab) · Make Help Center · accessed
- Credits & operations (opens in a new tab) · Make Help Center · accessed
- How is task usage measured in Zapier? (opens in a new tab) · Zapier Help Center · accessed
- Trigger (opens in a new tab) · Zapier Platform Docs · accessed