Search "n8n vs Zapier vs custom" and you'll drown in feature matrices — grids of checkmarks comparing trigger counts and app integrations as if the decision were a spec contest. It isn't. We've built automation on all three, and the feature list almost never decides the right tool. What decides it is a handful of questions about your specific situation. Here's the framework we actually use.
What each one is genuinely good at
Zapier is the fastest path from idea to working automation. Its strength is breadth — it connects to nearly everything, and a non-technical person can wire up a useful flow in an afternoon. Its weakness shows up as things get complex or high-volume: branching logic gets awkward, and the pricing scales with task count in a way that can sting once a workflow runs thousands of times a month.
n8n sits in the middle, and it's where a lot of serious SMB automation should live. It's visual like Zapier but far more capable with branching, loops, and custom code when you need it. It can be self-hosted, which changes the cost curve completely — you're paying for a server, not per-task — and keeps sensitive data on infrastructure you control. The tradeoff is that it asks more of whoever builds and maintains it.
Custom — actual code — is the right answer when the logic is genuinely yours: complex rules no off-the-shelf node models well, tight performance requirements, deep integration into a product you're building. It's the most flexible and the most durable. It's also the most expensive to build and the one most dependent on having someone who can maintain it. You reach for it when the others would be fighting the tool instead of using it.
The questions that actually decide it
Forget features. Answer these five, honestly.
1. Volume. How many times will this run a month? Dozens? Zapier's convenience is worth the per-task price. Tens of thousands? Per-task pricing becomes the dominant cost, and a self-hosted n8n or custom job pays for itself fast.
2. Logic complexity. Is it "when this, do that," or is it "when this, check three conditions, branch, loop over a list, and handle four edge cases"? Simple and linear favors Zapier. Branching and stateful favors n8n. Genuinely intricate favors custom.
3. Who maintains it. This is the question people skip, and it's often the most important. If the person keeping this alive is non-technical, a brittle custom script is a liability the day its author is unavailable. Match the tool to the team that has to live with it, not to the team that builds it.
4. Data sensitivity. Is regulated or confidential data passing through? Routing protected health information through a third-party cloud connector raises questions a self-hosted n8n or a custom job on your own infrastructure can sidestep. Where the data lives matters as much as what the automation does.
5. The cost curve, not the cost. Don't compare today's price; compare the slope. Zapier is cheap to start and gets expensive with scale. Self-hosted n8n has a flatter curve — more setup, less growth in cost. Custom is front-loaded: expensive to build, cheap to run. Pick the curve that matches where this workflow is heading, not where it starts.
Why the answer is usually two
Here's the part the matrices miss. Most businesses shouldn't standardize on one tool — they should use the right one per workflow. A typical healthy setup looks like Zapier handling the long tail of simple, low-volume connections nobody wants to think about, and n8n carrying the handful of high-volume or logic-heavy workflows that are the actual backbone. Custom shows up only where something is genuinely core and genuinely yours.
Trying to force everything into one tool is how you end up either paying Zapier prices for industrial volume or hand-coding a flow that a visual tool would have handled in twenty minutes. The skill isn't picking the one winner. It's matching each workflow to the tool whose strengths fit it.
The wrong question is "which tool is best." The right question is "which tool is right for this workflow, and who has to maintain it."
Three mistakes that cost the most
Most automation regret traces back to one of three errors, and none of them is about picking the "wrong" tool in the abstract.
Overbuilding. The most common one is reaching for power you don't need. A simple two-step automation gets built as a custom service because custom felt more "serious," and now a five-minute Zapier flow is a codebase someone has to host, monitor, and maintain. Power you don't use isn't an asset — it's a liability you pay for in maintenance. Default to the simplest tool that comfortably does the job, and only move up when the job actually demands it.
Ignoring the maintenance question. The build is a one-time cost; maintenance is forever. A clever custom script that only its author understands is fine until that person is on vacation and it breaks. We've walked into plenty of situations where the automation works perfectly and nobody dares touch it, which means it can never be changed — and an automation you can't change is a slow-motion problem. Always ask who owns this after launch, and build for that person, not for the cleverest possible solution.
Choosing on sticker price. Teams compare the monthly cost today and pick the cheapest, ignoring the slope. Zapier looks cheap until a workflow runs a hundred thousand times a month. Custom looks expensive until you realize it runs for years at almost no marginal cost. Decide based on where the workflow is heading, not where it sits on day one — the cheap option at launch is frequently the expensive one at scale.
Notice that all three mistakes are about fit and time, not features. That's the whole point. The tools are all good. The failures come from matching them to the wrong situation, or from forgetting that someone has to live with the choice long after the excitement of building it wears off.
A simple decision path
When we're scoping a new automation, the path usually runs like this. Start by assuming Zapier — if it's low-volume, simple, and the data isn't sensitive, stop there and ship it today. If volume is high or the logic branches, move to n8n. If the data is regulated or needs to stay on your own infrastructure, n8n (self-hosted) or custom. And only when the logic is genuinely unique, performance-critical, or embedded in a product you're building does custom become the answer.
The goal is never to use the most powerful tool. It's to use the least powerful tool that comfortably does the job — because that's the one that's cheapest to run, easiest to maintain, and least likely to become someone's problem six months from now.