Blog
n8n vs Make vs Zapier vs custom code: where each one stops working
All four are in our stack. Here's the actual line where a no-code tool starts costing more than it saves, and when writing code is the cheaper option.
TL;DR — Zapier is the easiest to start with and the first to get expensive. Make is the best balance of visual clarity and real branching logic. n8n is the one you self-host when data residency or per-task pricing stops making sense. Custom code is what you reach for the moment error handling, high volume, or genuinely custom logic makes a canvas harder to maintain than a function. We use three of these four regularly — Zapier rarely makes the cut, for reasons below.
The four, side by side
| Zapier | Make | n8n | Custom code | |
|---|---|---|---|---|
| Time to first working automation | Minutes | Under an hour | An hour or two | Days |
| Pricing model | Per task, climbs fast | Per operation, more headroom | Per execution (cloud) or flat (self-hosted) | Your infra cost only |
| Self-hosting | No | No | Yes | Yes |
| Branching / error handling | Basic | Good | Good | Unlimited |
| Debugging a failed run | Limited history | Clear execution log | Clear execution log, inspectable | Full control — logs, retries, alerts you design |
| Ceiling before it breaks down | Low | Medium | Medium-high | None — the ceiling is your own build time |
Zapier: fastest to a demo, first to hurt
Zapier’s onboarding is genuinely the best of the three no-code tools — you can connect two apps and see something work in five minutes. The problem shows up a month later, when task-based pricing meets real volume. A workflow that touches 10,000 records a month at three steps each is 30,000 tasks, and Zapier’s pricing curve punishes that shape of usage hard. It’s also the most limited of the three on branching: anything past “if this, then that, maybe with one filter” starts fighting the tool instead of using it.
We reach for Zapier only when a client already has it wired into their stack and the workflow is genuinely simple enough that migrating it elsewhere isn’t worth the disruption.
Make: the one we default to for visual workflows
Make’s canvas is denser than Zapier’s — more visible at once, real branching, a router that doesn’t feel bolted on. Its per-operation pricing is more forgiving of high-volume, low-complexity workflows than Zapier’s per-task model. Error handling is a first-class concept: you can catch a failure at a specific step and route it, not just watch the whole run die.
Where it stops being the right tool: workflows where the logic itself is the hard part, not the plumbing between apps. Deep conditional logic with a lot of state to track becomes a very wide canvas that’s hard for anyone but its original author to read six months later.
n8n: when self-hosting or per-execution pricing matters
n8n does most of what Make does, with two differences that matter for certain clients: it can be self-hosted (data never leaves infrastructure you control, which comes up constantly with clients handling client data of their own — recruiters, agencies, healthcare-adjacent work), and its pricing on a self-hosted instance is flat regardless of volume, not metered per execution. The tradeoff is that you’re now responsible for that instance running — updates, uptime, backups — which is a real cost even if it’s not a line item on an invoice.
We build in n8n specifically when a client’s compliance posture or data handling terms rule out sending anything through a third party’s cloud.
Custom code: when the logic outgrows a canvas
Every one of the three no-code tools above eventually hits the same wall: a visual canvas is a good way to represent “step A, then step B,” and a bad way to represent “step B unless three separate conditions from steps A and D both hold, in which case retry with backoff and page someone after the fourth failure.” At that point we write code — usually TypeScript or Python, either as the whole workflow or as a single step the no-code tool calls out to.
Code is also where we land the moment volume gets serious. A workflow processing tens of thousands of records a day is either going to be expensive on a per-execution platform or slow on one with rate limits designed for lighter use. Custom code has no ceiling on either — the constraint becomes your own engineering time, not a vendor’s pricing tier.
How we actually decide
Two questions, in order:
- Does the logic branch on real conditions, or is it linear? Linear — even a long chain — is fine in Make or n8n. Real branching with several independent conditions is where a canvas starts working against you.
- What’s the volume, and does the data need to stay put? High volume or strict data residency pushes toward n8n (self-hosted) or code. Low-to-medium volume with no residency constraint is comfortably Make territory.
We don’t default to code because it’s more impressive to build — a well-built Make scenario that a client’s own team can read and modify without calling us is usually the better outcome. Code earns its place when the no-code option would cost more in workarounds than the code would cost to write and maintain.
Have a workflow and not sure which of the four fits? Tell us what it does. Related: Automation systems if it’s ongoing sync between tools, Integrations & migrations if it’s a one-off move or a two-way sync with conflict handling.