n8n vs Make vs Zapier vs custom build: how to choose
There is no winner in this comparison, which is the most useful thing about it. Zapier is the right answer when speed to a working automation matters more than the cost of each run. Make is the right answer when the workflow branches and loops but the budget is tight. n8n is the right answer when self-hosting, control and data residency matter more than convenience. And a custom build is the right answer when the workflow is not an admin convenience but the business itself.
Most bad automation decisions are not bad tools. They are the right tool for somebody else's situation, chosen because a video made it look easy or because the person recommending it sells it. The honest way to choose is to start from your volume, your data sensitivity, and the person who will maintain the thing in eighteen months, then let the tool fall out of those answers.
We build on all four, so nothing below is a sales pitch for any of them.
What is each tool actually good at?
Zapier's strength is breadth and approachability. Its integration catalogue is enormous, a working trigger-and-action automation can exist within an hour, and a competent office manager can maintain it without a developer. You pay for that convenience through its pricing model, which charges per task, so cost tracks volume.
Make is a visual scenario builder. Routers, iterators, error handlers and loops are all first-class, so genuinely complex logic stays on one canvas, and its per-operation pricing model tends to make complexity cheaper to run than the equivalent chain of Zapier steps. The trade is a steeper learning curve.
n8n is the control option. It is source-available and can run on your own server, which means workflows, credentials and the data passing through them stay on infrastructure you choose. For firms handling client-confidential or personal data, that is not a nice-to-have: under UK GDPR you remain the controller wherever the workflow runs, and the ICO's guidance for organisations is the place to check what that duty involves.
Custom code has no platform ceiling at all. It costs the most up front, and it is the only option where the system can be shaped exactly around the business rather than the business bending around a platform.
Which option fits which scenario?
| Your situation | Sensible default | Why |
|---|---|---|
| Low volume, mainstream apps, needed this week | Zapier | Fastest to working, easiest to hand over |
| Complex branching logic, price sensitive | Make | Per-operation model suits many-step scenarios |
| Personal or client-confidential data, residency requirements | n8n, self-hosted | Data stays on infrastructure you control |
| High and growing run volume | n8n or custom | Per-task pricing punishes volume; self-hosting does not |
| Nobody technical in-house, no partner | Zapier | The one a non-developer can genuinely maintain |
| Deep integration with legacy or niche systems | n8n or custom | Code nodes and raw API calls reach where connectors do not |
| The workflow is the product or the margin | Custom | You do not build the business on a rented ceiling |
Read the table by row, not by column. The same firm can correctly run Zapier for calendar admin and a custom build for the process that wins them work.
How does each one fail?
Every option has a characteristic failure mode, and choosing well means choosing the failure you can live with.
Zapier fails quietly and expensively. A zap that errors repeatedly can switch itself off, and nobody notices until the CRM is three weeks stale. Meanwhile per-task costs creep as the business grows, and the workaround culture (many small zaps instead of one designed flow) leaves nobody with a full picture.
Make fails through complexity debt. A scenario built over a year by one enthusiastic person becomes a wall of modules only that person can read. When they leave, the firm owns a diagram it is afraid to touch.
n8n fails at the infrastructure layer. Self-hosting means updates, backups, access control and monitoring are your job, and an unmaintained server is a liability rather than an asset. The basics in the NCSC small business guide are the minimum standard for anything holding your credentials.
Custom builds fail through key-person risk: undocumented code and a departed developer. The cure is boring and known (documentation, handover, a maintenance arrangement), but it has to be priced in on day one, not discovered in year two.
What do the pricing models actually tell you?
Ignore the headline numbers, which change, and look at the shape of each model. Per-task pricing (Zapier) is predictable at low volume and punishing at high volume. Per-operation pricing (Make) rewards efficient scenario design and penalises waste. Self-hosted (n8n) is a roughly flat infrastructure cost plus your time, so the marginal run is essentially free while the maintenance is not. Custom is a build cost plus hosting plus a support arrangement, with no per-run meter at all.
The crossover question is simple: multiply your realistic monthly run volume a year from now by the per-unit model, and compare it with the flat-cost options including the labour to maintain them. Do that arithmetic with your own numbers, not a vendor's example.
When should the tool question come second?
Almost always. The valuable work is upstream: deciding which process is worth automating, what the trigger really is, and what happens when it fails, which is why we describe the work as automation rather than software. A well-chosen boring tool running an automation that needs no prompting beats an impressive platform nobody trusts.
If you want a second opinion on which of the four fits a specific process, that is exactly what our workflow automation service starts with, and the answer is regularly the cheapest option on the list. The tool was never the decision. The maintenance plan was.