Every business we talk to eventually asks the same question: which tool should we actually use? Zapier, Make, n8n, something custom — there are more options than there used to be, and most of the comparisons online are written by the tools themselves.
Here’s how we’d think about it if we were starting from scratch.
The real question is speed versus control
The honest answer is that most of these tools can technically do the job. The difference isn’t capability, it’s how much time you want to spend setting it up versus how much control you want once it’s running.
Zapier optimises for speed. Make and n8n optimise for control, at the cost of a steeper setup. Custom code optimises for control taken all the way, at the cost of needing someone who can write and maintain it. None of these is the “correct” choice in the abstract — the right one depends on the process, not on which tool has the best marketing.
Zapier: the fastest way to stop doing something by hand
If you’ve never automated anything before, Zapier is usually where to start. The interface is built for people who don’t think in workflows for a living, most common business tools already have a ready-made connection, and you can have something running in under an hour.
The trade-off shows up once a workflow gets more than a few steps, or needs a decision more complicated than “if this field says X, do Y.” Zapier’s pricing also scales with volume in a way that can surprise you if a workflow runs often — worth checking before you build something you’ll rely on daily.
Good fit for: a single, fairly simple process, and a team with no appetite for a learning curve.
Make and n8n: more power, more setup
Make (formerly Integromat) and n8n both use a visual, node-based canvas rather than Zapier’s linear steps. That makes them better suited to workflows with branches, loops, or several data sources feeding into one process — the kind of thing that gets clumsy in Zapier fast.
n8n has a meaningful extra advantage for a lot of businesses: it can be self-hosted, which matters if you’re handling client data you’d rather not send through a third party’s cloud, or if per-execution pricing would get expensive at your volume. The cost is that someone on your side needs to be comfortable with slightly more technical setup — not coding, but more than dragging a few blocks together.
Good fit for: a process with real branching logic, multiple systems involved, or data sensitivity that makes self-hosting attractive.
When no-code isn’t enough
Occasionally the honest advice is that none of the above is right. If a workflow needs genuine judgement — reading a message and working out what it means, rather than matching a keyword — you’re often better served by a small custom build using an AI model directly, wired into just the two or three systems you actually need. No-code platforms can call AI models too, but once the logic gets complex, a purpose-built script is usually easier to maintain than a sprawling no-code flow trying to do too much.
This is also where a lot of DIY automation projects quietly stall: someone builds something impressive in Make or n8n, it works in testing, and then it becomes unmaintainable the moment the business needs to change one small thing about it, because nobody documented the twelve-step logic chain that got it there.
Pick the tool after you’ve mapped the process, not before
Tool choice is a five-minute decision once you actually know what the process needs to do — which is exactly why we map the process first with every Foundation Client. Choosing the tool before you understand the workflow is how businesses end up rebuilding the same automation twice, in two different platforms, a year apart.
If you’re not sure which of these fits what you’re trying to fix, that’s a fair thing to ask before committing to any of them — get in touch and we’ll tell you straight, whether or not it ends up being us who builds it.