Make vs n8n vs Zapier vs custom code: when each one wins for a builder

Choose the tool by the client, not by preference: Make or Zapier when the business will open and adjust the workflow itself, n8n when the data must stay on infrastructure the client controls or the logic gets branching-heavy, and custom code when the automation needs its own interface, unusual integrations or high volume. All four can build the same first pilot. They differ in who can maintain it, what it costs to run, and how it fails. This guide gives the decision tree and the after-launch trade-offs that decide most projects.

The question that decides it: who touches this after launch?

The build takes two weeks. The automation runs for two years. The tool decision is really a maintenance decision. If the owner or their office manager will ever need to change a message template, add a field or pause a step, they need a visual tool they can open. If only you will ever touch it, the choice widens.

The four options, compared for a builder

Every cell is a trade-off, not a verdict. A clinic sending 300 reminders a month has different constraints from an e-commerce shop syncing 30,000 orders.

When Make wins

Small and mid-sized businesses that want to see the workflow. Rich modules for the tools Israeli SMBs use (WhatsApp providers, Google Workspace, popular CRMs). Good error handling and routers for moderate branching. Watch operation counts on chatty scenarios, and document each scenario so the client isn't lost when you're away.

When n8n wins

Any project where the client asks "where does our data go?" and the honest answer needs to be "your server". Also for logic-heavy flows and when you want to write a small function inside a step without leaving the tool. The price is upkeep: someone maintains the instance, updates and backups. Say who, in the retainer.

When Zapier wins

The simplest integrations for non-technical teams: one trigger, a couple of actions, no branching. Fast to set up, easy for the client to own. Costs climb with volume and complex logic gets awkward; when a Zap needs paths and filters everywhere, it's time for Make or n8n.

When custom code wins

A user interface the business will use daily, an integration no platform supports, volumes where per-operation pricing hurts, or logic that would be unreadable as boxes. Custom code is also the right answer when the client has a developer who will own it. It is the wrong answer when its only owner is you and the client can't see inside.

Mixing them, deliberately

Many good builds are hybrid: a Make scenario for the workflow the client can see, calling one small custom function for the part that needed real code. Keep the client-facing shape simple and put the complexity behind one well-documented step.

What to tell the client

Explain the choice in one sentence of consequences, not features: "We'll build it in Make so your office manager can change the message text herself; if we ever need your data to stay on your own server, we'd move it to n8n." Owners trust a builder who names the trade-off.

Best fit and not a good fit

Best fit: builders choosing a platform per project instead of by habit. Not a good fit: picking the tool before the audit. The audit tells you who maintains it, what the data is, and what the volume is; the tool follows.

What to do this week

Take your last project and run it through the decision tree. If you'd choose differently now, write down why: that reasoning is what you'll say to the next client.