ShiftAIn8n, Make or Zapier: which fits a professional firm?
Should my firm use n8n, Make or Zapier for automation?
Choose on operating model, not features. Zapier suits a handful of simple connections owned by a non-technical person, Make suits moderate complexity in the cloud, and n8n suits firms that want self-hosting, control over where data sits, or enough volume that per-task billing stops making sense. All three will connect the tools a typical firm already uses, so the deciding factor is usually maintenance and hosting rather than capability.
What actually separates these three?
Hosting model. Zapier and Make are vendor-hosted only, which means your workflows run on their infrastructure and you rent access. n8n can run the same way through its own cloud offering, or on a server you control. Almost every other difference follows from that one architectural fact.
Vendor hosting means someone else patches the servers, handles uptime and absorbs the operational burden. That is a genuine service, and for most small firms it is the right trade. Self-hosting means you decide where the data physically sits and what the running cost is, and you accept the maintenance in exchange.
The second real difference is portability. n8n workflows are JSON files you can export and keep in a repository your firm owns. Make scenarios can be exported as blueprints. Zapier is the least portable of the three, so if you are building anything you would hate to lose, check what an export actually gives you before you commit.
Does your firm need to self-host?
Probably not, unless you have a specific reason you can name. Self-hosting solves data residency, cost at high volume, and workflows that need custom code. It does not solve anything else, and it adds a server to your list of things that can go wrong.
The reasons that genuinely justify it in a professional practice:
- A client contract or professional indemnity condition that constrains where data is processed.
- A large client or regulator who has asked, in writing, where the data sits.
- Client information sensitive enough that your own risk register already treats third-party processing as a control point.
- Volume high enough that per-task billing becomes a meaningful line item.
On the Australian side, if personal information about your clients passes through an overseas provider, that is a cross-border disclosure question your firm needs an answer to. The practical version is simple: know which countries the data touches, and make sure your privacy policy and client agreements match what actually happens. Anything more specific than that is advice about your practice, and you should get it from someone engaged to give it.
The honest counterweight: a self-hosted server that nobody patches, backs up or monitors is worse for client data than a vendor-hosted platform with a real security team. If no one in the firm will own that job, vendor hosting is the safer answer.
How do the three compare on criteria that last?
| Criterion | Zapier | Make | n8n |
|---|---|---|---|
| Where it runs | Vendor cloud only | Vendor cloud only | Vendor cloud or your own server |
| Control over data location | Whatever regions the vendor offers; verify current terms | Whatever regions the vendor offers; verify current terms | Complete, when self-hosted |
| Shape of the billing | Historically per task or step | Historically per operation | Per execution on cloud; infrastructure cost if self-hosted |
| Complexity ceiling | Lowest; comfortable with linear flows | High; branching, iteration, error paths | Highest; custom code, queues, long-running jobs |
| Skill needed to build | A capable non-technical person can start | Ops-minded person with some training | Technical builder or a trained internal owner |
| Portability of the workflow | Least portable; check what export gives you | Blueprints exportable | JSON files you can keep in your own repository |
| Size of the connector catalogue | Largest | Large | Large, plus a generic HTTP option for anything missing |
Treat the billing row as the shape of the model rather than a current fact. All three have changed their pricing structure before and will again, so check the pricing page on the day you decide.
What will it actually cost to run?
You cannot answer that from an article, because the rates move. What you can do is work out your own volume first, then price it against whatever the platforms publish this week. That order matters, because volume is the number that determines which pricing model punishes you.
- Count the runs. How many times a month does the trigger actually fire? Enquiries received, invoices raised, matters closed.
- Count the steps in each run. On a per-task platform, a seven-step workflow costs seven times what a one-step workflow costs at the same volume.
- Multiply the two and look up which tier that lands in on each platform today.
- Price the model usage separately. If the workflow calls an AI model, that is metered by the model provider under your own key and is not included in the automation platform's fee.
- If you are considering self-hosting, add the server cost plus a realistic hour or two a month of someone's attention.
- Re-run the whole calculation in twelve months, because your volume will have changed even if the prices have not.
The pattern worth understanding: per-task pricing is cheap while you have two simple workflows and gets expensive as you add steps and volume. It bills you more precisely as your automation matures, which is exactly backwards from what you want. Per-execution and self-hosted models flip that curve.
Who is going to maintain this?
Name that person before you choose the tool, because the answer decides more than any technical criterion. Automation that nobody owns quietly rots the first time an API changes.
- If the maintainer is your office manager or a partner's assistant, Zapier. It is the most forgiving and the easiest to reason about without training.
- If the maintainer is an ops-minded person who likes systems and has a few hours to learn, Make. It handles real branching and error handling without needing code.
- If the maintainer is a technical person, or an external builder who hands over documented work, n8n. The ceiling is higher and the workflow files are yours.
Whoever builds it, the accounts and API keys should sit in your firm's name from day one. That is a separate question from which platform you pick, and it matters more.
When is each one the right pick?
- Zapier when you have a handful of simple connections, no technical person in the building, modest volume, and the apps you use are well supported.
- Make when you need real branching, retries and error routes, your volume is moderate, and someone in the firm will own it properly.
- n8n when data residency matters, volume is high, the logic needs custom code, or you want the workflow files sitting in a repository you control.
- None of them when the process itself is still undocumented or changes every month. Automating an unstable process just makes the instability run faster.
What to do next
Write the workflow out on paper first, in the order a human does it today, including the exceptions. Count how many times a month it runs and how many steps it takes. Then open all three pricing pages on the same afternoon and price your actual volume rather than a hypothetical one.
Pick the platform your named maintainer can actually maintain, build one workflow end to end, and run it for a month before you build the second. If you would rather have someone else make that call with you and put a fixed scope around it, that is the kind of conversation Shift has on a fit call. Either way, the tool is the smallest decision here. The process you point it at is the big one.