Zapier vs Make vs n8n: the three questions that actually decide it

A four-person insurance office built 37 workflows in a visual automation tool over two years. The person who built them left. The remaining staff could keep the workflows running, but nobody could change them, and when the vendor changed how it charged, those 37 workflows stopped being cheaper than the part-time admin they had been built to replace. The rebuild took three weeks and was done in a different tool.

Nobody in that office would say they chose wrong on price. They chose wrong on the three questions below.

The three questions that actually decide it

Forget the feature lists for a moment. In practice, one of these three questions narrows the field for almost every small business.

1. Who maintains it in six months? Not who builds it — who edits it at 4 p.m. on a Friday when an online form changes its field names. If the answer is "whatever developer we found", the tool must be one a developer wants. If the answer is the office manager, the tool must be one a non-technical person can read.
2. How many steps and branches does the workflow really have? A single trigger-action pair ("new form entry → send a text") is a different animal from a workflow with conditional branches, loops over a list, and error retries. Complexity is what turns a friendly tool into an unreadable one.
3. Does the data need to stay in-house? If the workflow handles payment details, health information, or client records under a policy that says the data cannot leave your systems, that single constraint may decide the tool before anything else.

A decision table

This table is about fit, not ranking. None of these is universally best; each is the wrong choice in some situation.

Notice how often the "watch out for" column is the sentence that decides it. Every tool here has a version of "and now you own a new thing".

The real cost of the wrong choice

Buyers compare monthly license cost. That is the smallest number in the decision.

The expensive number is the rebuild. When a workflow outgrows its tool — too many branches, the price model turns against you, or the one person who understood it leaves — you do not migrate a file. You reconstruct logic from memory, re-test every branch, and re-earn trust in a process the business now depends on. In the insurance office above, the license was never the problem. Three weeks of reconstruction was.

So price the decision like this:

Real cost of a tool = license per month × months used
                    + (your hourly rate × hours to build the first workflow)
                    + (probability it must be rebuilt × cost to rebuild)

You cannot know the third term exactly, but you can ask an honest question about it: how likely is it that this workflow grows past this tool in the next two years? If the answer is "quite likely", a tool that scales structurally is cheaper even if it costs more per month. Check current pricing for any of them before you decide — the models have changed more than once and are not worth quoting from memory.

When no tool wins

There is a category of automation where all three are the wrong answer: a workflow that runs on a schedule, moves data between two systems you already own, and has one job to do with no decisions in it.

For that, a scheduled script or a direct API call is smaller, faster, and easier to reason about than any visual builder. The trade is real — it needs someone who can write and read code, and it has no drag-and-drop safety net — but a 40-line script that runs on a cron schedule does not have a dashboard, a task quota, or a vendor who can change the pricing. If your team has a developer, this is often the correct answer and the one nobody proposes, because it is not a product you can buy.

The maintenance question most buyers forget

Every tool on this list works on day one. The question that separates them is what happens on day 400, and it has three parts:

1. Can someone other than the builder read it? Hand the workflow to a colleague and ask them to explain what it does. If they cannot, you have a single point of failure with a login.
2. What happens when the source app changes? Forms rename fields, APIs version, platforms deprecate endpoints. Who notices, and how fast?
3. What is the exit? If you had to leave this tool in a year, could you get your logic and your data out, and how long would it take? A tool that cannot be left cheaply is a tool you are stuck with.

Write the answers down next to the cost. Two tools can cost the same per month and have wildly different odds of surviving your next staff change.

What to do today

• Draw the workflow on paper — every branch and every failure path — before you open a signup page.
• Answer the three questions in writing: who maintains it, how complex it really is, whether the data can leave.
• Give your own answer to the maintenance question, especially the exit.
• If a developer is available and the workflow is scheduled and fixed, price the plain-script option before you price a subscription.

Pick the tool you can still change in six months. Everything else is a detail.