Zapier, Make, n8n or a custom build, and how to tell which one you need

The short version

If you want the answer without the reasoning, it is almost always the first line of this table that applies to you.

Start here: the automation you already pay for

Before comparing anything, check what your existing tools already do. Booking systems, CRMs, invoicing tools, ecommerce platforms and phone systems ship with automation built in, and in most businesses a meaningful share of it has never been turned on.

This is unglamorous and it is free, in the sense that you are already paying for it. It is also the fastest way to find out whether automation actually helps your business before committing to anything.

• Your booking tool almost certainly sends reminders and can chase no-shows. Most businesses use neither.
• Your invoicing tool can chase overdue payment on a schedule, which is the single most common manual job we find still being done by hand.
• Your ecommerce platform has abandoned-cart and post-purchase flows sitting unconfigured.
• Your phone system may already do missed-call notification, and sometimes missed-call text back.
• The test: if the whole job happens inside one tool, it does not need a connector between tools. Reaching for Zapier here adds a dependency and a bill to something you already own.

Zapier

The most widely used of the three, with the largest catalogue of connected apps and the shallowest learning curve. It is built so a non-technical person can connect two tools and have something working the same afternoon, and it delivers on that.

What you are buying is reach and speed. It is priced on task volume, which means the economics are excellent while volume is low and become the deciding factor as volume grows. Anyone who has run a busy workflow on it for a year knows where that line is.

• Best at: a small number of connections between well-known tools, built quickly by whoever needs them, with no engineer involved.
• Where it strains: branching logic, loops, transforming awkward data, and anything that needs to retry intelligently rather than just fail.
• The real cost that surprises people: not the bill, the sprawl. Forty little automations built by five people over two years, none documented, several doing overlapping things, and nobody willing to delete any of them.
• Not for: workflows where the logic itself is complicated. That is a statement about what it is designed for, not a criticism of it.

Make

Visual, more powerful than Zapier at the same kind of job, and priced on operations rather than tasks, which usually stretches further for the same work. The canvas makes multi-step scenarios with real branching genuinely readable, and it handles data transformation far more comfortably.

The trade is a real learning curve. Someone in the business has to want to learn it, and the same visual canvas that makes a ten-step scenario clear makes a sixty-step one a wall somebody has to maintain.

• Best at: multi-step workflows with conditions, iteration and messy data, built by someone technical enough to enjoy it.
• Where it strains: the point where a scenario becomes software. Version control, testing and code review are not what a canvas is for.
• The real risk: one person builds everything and it lives in their head. This is a staffing problem, not a tooling one, and it is the most common way a Make setup becomes a liability.
• Not for: a business with nobody willing to own it. It rewards an invested owner and punishes an absent one.

n8n

Source-available and self-hostable, with a cloud option. The distinguishing feature is that you can run it on infrastructure you control, which changes two things: there is no per-task meter on your own instance, and your data does not have to leave your environment.

Both of those matter more in some businesses than others. If you are running high volume, the volume economics are the argument. If you handle health, financial or legal information, the data residency argument is stronger still, and under Law 25 it is the one that will come up in a compliance conversation.

• Best at: high volume, or any workflow where the data genuinely should not sit on someone else's platform.
• Where it strains: it is infrastructure. Hosting, upgrades, backups and uptime become yours, and that is a real job however small.
• The honest catch: self-hosting to avoid a subscription only pays if nobody has to spend their week on it. Count that time before deciding it is the cheaper answer.
• Not for: a business with no appetite for running infrastructure. The cloud option exists precisely for that, and choosing it is a perfectly sensible outcome.

A custom build

This is what we do, so treat what follows with appropriate suspicion and check it against your own situation.

A custom build is right when the logic is the thing. Not "we connect these two tools", but "how we decide which enquiry is urgent, what we decline, when we chase and who we escalate to is specific to us, and it is the part that makes the business work". At that point a connector is being used as a programming language, badly, and it deserves to be treated as software instead.

• Best at: logic that reflects how you actually operate, systems that need to be tested and versioned, and anything that has to survive the person who built it leaving.
• Where it strains: speed of first result. A connector gives you something this afternoon; a build gives you something in a week or three.
• The honest catch: it is only worth it if the workflow is stable enough to be worth encoding. Automating a process you are still arguing about is expensive.
• Not for: common problems with good products already solving them. Buy those. The argument in full is in build versus buy.

The thresholds where one becomes the next

These are the actual trigger conditions, rather than a general sense that you have outgrown something. If none of them describe you, stay where you are.

1. Built-in to a connector: the job crosses two tools that do not talk to each other, and you have already confirmed neither has a native integration.
2. Zapier to Make: you are building multi-step logic with conditions and it has become awkward, or the task meter has become the thing you optimise around rather than the workflow.
3. Make to n8n: volume has made the metered model the dominant factor, or a compliance requirement means the data should not sit on a third-party platform at all.
4. Any of them to a custom build: the workflow is now genuinely software, several people depend on it, nobody can read it end to end, and a failure has real consequences. That combination is the signal, not any one of them alone.
5. Any of them to nothing: worth saying. Some automations should be deleted rather than migrated. A workflow nobody has looked at in a year is a liability, not an asset.

What we would tell you in a first call

Something close to this, in this order. It is not a sales script, it is just the order that avoids wasting everybody's time.

• What have you already tried? If the answer is nothing, go and switch on what you own and come back in a month. You will know far more about your own constraints.
• What breaks when it goes wrong? If the answer is "somebody fixes it in the morning", a connector is probably fine forever. If it is "we lose the customer", that changes the answer.
• Who will own it? A tool that nobody owns fails regardless of which one you picked. That is covered in what a broken automation costs.
• Is the process settled? If you are still changing how you handle enquiries every month, encode nothing yet. Use the flexible thing until the process stops moving.
• Where does the data have to live? Usually irrelevant, occasionally the entire decision, and always worth thirty seconds. The Quebec specifics are in the Law 25 guide.

Where this leaves you

The order of the four answers is not a ladder you are supposed to climb. Most businesses should find their level and stay there, and for a large share of them that level is a connector doing five useful things reliably, forever.

Where a custom build earns its place is when the logic is yours and the consequences of it being wrong are real. If you are not sure which category your problem is in, the automation scanner ranks the seven categories of work against how your week runs, and the ninety day roadmap covers the order to build in whichever answer you land on.