n8n vs Make vs Zapier vs custom. Choosing an automation backbone.

How do n8n, Make, Zapier and custom code compare?

n8n, Make, Zapier and custom code all move data between your tools when something happens. They differ in four ways that decide the right pick: what each one bills for, where it runs, how much code it allows and who on your team can keep it working.

Why does the pricing unit matter more than the monthly fee?

The pricing unit decides how the bill grows. Zapier counts each successful action step as a task and Make counts each module run, so a longer workflow costs more per run. n8n Cloud counts one execution per workflow run, however many steps it has, so adding a safety check costs nothing extra.

Take an illustrative workflow of the kind our AmazeOps builds run daily. A new inquiry arrives, gets validated, enriched, written to the CRM, booked into the calendar and confirmed by text. That is a trigger and five actions. Run it 3,000 times a month.

Which tool is cheaper depends on plan prices, and those change. The steady effect is on behavior: when each extra step costs money, teams cut validation and error-handling steps to save units, and those are the steps that keep a workflow from doing damage.

When is Zapier the right answer?

Zapier is the right answer more often than automation builders admit. For a service business, it fits when the workflow is short and low-volume, the person fixing it works in operations rather than engineering, and a failed run costs a spreadsheet row rather than a booking.

• The workflow is short and linear, and runs a few hundred times a month.
• The person who will fix it works in operations or marketing, not engineering.
• A failed run is an inconvenience, such as a missing row in a sheet, rather than a lost booking or a missed payment.
• You are still learning what the process should be. Changing a Zap takes minutes.

We tell clients this regularly, and it costs us builds. It is also why the rest of our advice gets believed.

Choose on who will fix it at 7 PM on a Friday, not on the monthly fee.

Signal No. 05

When does custom code earn its cost?

Custom code earns its cost when a failed run loses money, as with a booking write, a payment or a consent check, when data such as patient records cannot leave your infrastructure, or when the monthly bill for tasks or credits outgrows what an engineer's time would cost. Most production systems we run end up as hybrids.

The money-losing steps belong in code with tests, version control and someone who reviews changes. The rest can stay in a workflow engine.

Inquiry to booking· Northwind DentalActive

WebhookNew inquiry

ValidateCode · dedupe

Qualified?IF

HubSpotUpsert contact

CalendarCreate event

TwilioConfirm by text

GmailNurture email

Error triggerAny step fails

Alert ownerText and email

Last 24 h: 112 executions0 failed

On Sunridge Solar's build, the workflow engine runs calling windows and the callback queue, while code checks the do-not-call list, enforces quiet hours, writes the appraisal to the calendar and retries a failed CRM update. On Compass Trail's booking system, code decides who is eligible for a follow-up call and retries supplier confirmations that time out.

Can n8n, Make and Zapier run AI steps?

Yes. Zapier, Make and n8n can all call a language model as a workflow step. The design question is where the model's output gets checked before it changes anything, because a model is good at reading a messy inquiry and poor at deciding whether someone may be called or which slot is free.

Whether someone may be called, which slot is free and whether a payment cleared are rules, and rules belong in code or in a workflow step that cannot be talked out of them.

The case write-ups for Sunridge Solar and Compass Trail split the work the same way: the model holds the conversation and judges when a person is ready, and code does the rest. Whichever backbone you choose, draw that line first. A workflow where a model's free text goes straight into a booking or an outbound call is the one that will surprise you.

What mistakes show up a year after choosing an automation tool?

Three mistakes tend to surface about a year after a team picks an automation tool: keeping lists and flags inside the tool instead of the CRM, choosing on the monthly fee instead of the cost of a failed run, and stripping out error handling to save tasks or credits, which leaves failures silent.

1. They keep state inside the automation tool. Lists, flags and counters stored in the tool become a second database no one can query. Keep state in your CRM or a real database, and moving tools later is a rebuild of steps, not a migration.
2. They choose on the monthly fee. The cost that matters is the hours spent fixing it and what a failed run loses.
3. They skip error handling to save units. An automation without an alert fails silently. That is one of the four CRM automation failure modes.

Which automation tool fits your team?

Pick the automation tool by who will maintain it, then check volume and data rules. No technical staff points to Zapier, a technical operator to Make or n8n Cloud, and developers, high volume or strict data rules to self-hosted n8n or custom code.

No technical staff, simple flows

Zapier, owned by your operations lead, with the state kept in your CRM. Revisit when volume or logic grows.

A technical operator, branching logic, moderate volume

Make or n8n Cloud. Pick the one your operator reads more easily, which matters more than any feature on this page.

Developers on staff, high volume or strict data rules

n8n self-hosted or custom code, with code for the critical steps and the orchestration somewhere the whole team can see it.

Patient records, payments or other regulated data

The backbone matters less than the agreements, access controls and logs around it. A self-hosted tool still needs each connected service covered, and which BAAs a clinic's AI voice agent needs is the clinic version of that question.

An audit of the automations you already run

Make one list. It will tell you more than any comparison table.

1. Write down each automation you run, with its monthly runs and the person who fixes it.
2. Next to each one, write what a single failed run costs you: nothing, an hour, a customer.
3. Mark which ones alert a person when they fail. The unmarked ones with a cost are your first job.
4. Find any state, such as lists, tags or counters, stored inside the tool, and plan to move it into your CRM.

If the list is long and the costs are real, that is the work our workflow automation builds take on, and it usually starts with the handful of workflows where a failure costs a customer.