“Should we use n8n or Zapier?” is the wrong first question, but it’s the one every operator asks us. The right question is who maintains this workflow eighteen months from now, and where the data is allowed to live. Answer those two and the tool usually picks itself.

We run an MSP and ship our own product, so we’ve inherited automations built by every kind of team — the non-technical owner who wired up forty Zaps, the engineer who wrote a Python script nobody else can read, the school district that couldn’t put ticket data in anyone else’s cloud. Here is how we actually choose, and where each option breaks.

What each one is genuinely good at

Zapier is the right tool when a non-technical person owns the workflow and the apps involved have first-party Zapier connectors. Its real strength isn’t the integrations — it’s that a marketing coordinator can build and fix a Zap without filing a ticket. That ownership story is worth more than people give it credit for.

n8n is our default for SMB and public-sector work that needs real branching logic, self-hosting, or integrations with internal tools that don’t exist on Zapier. It’s source-available, you can run it on your own infrastructure, and it doesn’t bill you per task. We run n8n internally for our own MSP, which is the main reason we trust it under load.

Custom code — a small Node or Python service — wins when the workflow is the product, when the logic is genuinely novel, or when you’ve outgrown what a visual builder can express without becoming unreadable. It’s also the option most often reached for too early.

Make sits between Zapier and n8n: denser visual logic than Zapier, no self-hosting burden of n8n. Microsoft Power Automate is the obvious starting point when everything already lives in an M365 tenancy — SharePoint, Outlook, Teams, Dataverse — which describes a lot of municipal IT teams on the Peninsula.

Where each one breaks

No tool is free of failure modes. The ones below are the bills that arrive after the demo.

Zapier breaks on price at volume. It charges per task, and a “task” is every single step in a Zap. A five-step Zap that fires 2,000 times a month is 10,000 tasks, and that math turns a $20 plan into a four-figure annual line item faster than anyone budgets for. Zapier is cheap to start and expensive to scale — the opposite of what most operators assume.

n8n breaks on maintenance. Self-hosting means someone patches the server, manages the database, handles upgrades, and gets paged when the queue backs up. If you don’t have a person who owns that, self-hosted n8n becomes a single point of failure with no support contract. n8n Cloud removes the ops burden but gives back some of the data-residency advantage that made you choose n8n in the first place.

Custom code breaks on the bus factor. A bespoke service is a liability the moment the person who wrote it leaves. No visual flow to read, no vendor docs, just a repo and whatever the author remembered to comment. We say this on the agents page too: custom code is long-term maintenance cost, and you should only pay it when the alternative is fighting the framework.

Total cost of ownership, honestly

The sticker price is the smallest number. Here’s the full picture across the three.

	Zapier	n8n (self-host)	Custom code
Upfront build	Lowest	Medium	Highest
Run cost	Per-task — climbs with volume	Flat infra (a small VM)	Flat infra + hosting
Hidden cost	Task overage bills	Server patching + upgrades	The engineer who left
Who can edit it	Non-technical owner	Technical operator	Engineers only
Breaks loudly?	Yes — clear error logs	Mostly — needs monitoring	Only if you built logging

The cheapest tool to build in is rarely the cheapest tool to own. Zapier minimizes build cost and maximizes run cost at scale. Custom code does the reverse. n8n self-hosted trades a flat, predictable infra bill for an ops responsibility you have to staff. Pick the cost you can actually afford to carry, not the one that looks small on day one.

Data residency and self-hosting

This is the criterion that overrides everything else, and it’s why we don’t have a house tool — we have a house fit.

Some work is not allowed to live in a SaaS vendor’s cloud. CJIS-adjacent law-enforcement data, student records under FERPA, certain HIPAA workflows — the data can’t leave infrastructure the org controls. Zapier and Make are cloud-only, so they’re off the table before the conversation starts. Self-hosted n8n is usually the answer: it runs on your own VM, in your own VPC, behind your own firewall.

We’ve shipped exactly this for a Bay Area school district that couldn’t move ticket data outside its own network. n8n on their infrastructure, their database, their backups. The same workflow on Zapier would have been a compliance finding.

The residency-and-ownership test

When an operator can’t decide, we run two questions in order. The first one that returns a hard “no” makes the decision — you don’t get to the second question until the first one passes.

The order matters. Residency is a hard constraint — you either can or can’t put the data somewhere, and no amount of convenience overrides it. Ownership is the next filter because the best tool is the one the team can still run after the consultant is gone. A perfect Zap that only we understand is a worse outcome than a plain one your coordinator maintains.

Notice what isn’t in the test: the number of integrations, the prettiness of the builder, which tool we happen to know best. Those are tiebreakers, not deciders.

Who owns it after the consultant leaves

This is the part most automation projects get wrong, and it’s the cause of more dead workflows than any technical limitation.

If a workflow can only be edited by the firm that built it, you don’t own an automation — you own a dependency. The handoff is the deliverable. When we ship automation, the engagement includes a runbook, a 90-minute training session for the named owner, and 30 days of support so the team can fix the thing when an upstream API changes without calling us back.

That’s also why tool choice tracks ownership so tightly. We’d rather build a slightly less elegant Zapier flow that your operations lead can debug than a beautiful custom service that goes dark the day your one technical person takes another job.

When custom code is actually the right call

Custom isn’t a failure state — it’s the right answer in narrow cases. Reach for it when the integration genuinely doesn’t exist in any builder, when the logic is novel enough that a visual flow becomes unreadable, or when the workflow is core enough to your business that you want it under version control with proper tests.

The trap is reaching for custom because it feels more “real” than a no-code tool. It isn’t. A maintainable Zap beats an unmaintainable script every day of the week. Write code when the framework is the thing fighting you — not before.

If you’re still unsure which problem you have, the use-case clarity dimension in our AI Readiness Assessment surfaces whether your workflow is a fixed path (automation) or a branching decision that might want an agent instead.

Common questions

Is n8n cheaper than Zapier? At low volume, no — Zapier’s free and starter tiers beat the cost of running a server. At scale, almost always yes, because Zapier bills per task and self-hosted n8n bills you a flat infra cost regardless of how many times a workflow runs. The crossover usually arrives somewhere in the low thousands of tasks per month.

When should I use n8n instead of Zapier? When the data can’t live in a vendor’s cloud, when you need real branching logic, or when you’re hitting Zapier’s per-task pricing wall. The deciding factor is usually data residency or volume, not features. Run the residency-and-ownership test above.

What about Make or Power Automate? Make is a good middle ground when Zapier’s logic feels cramped but self-hosting n8n is overkill. Power Automate is the natural pick when the whole workflow lives inside M365 — for most municipal teams already on SharePoint and Teams, it’s where we’d start.

Can I self-host n8n for HIPAA or government data? Yes — that’s its strongest case. Self-hosted n8n runs on your own infrastructure, so ticket data, student records, or HIPAA-adjacent workflows never leave your network. We’ve shipped this for a Bay Area school district under exactly that constraint. You still need the security review and governance in place first.

Should we just build it custom to keep full control? Usually no. Custom code gives you control and takes away the bus factor — the moment its author leaves, you own a repo nobody can safely change. Build custom only when no builder can express the logic, or when the workflow is core enough to deserve real tests and version control.

The honest answer is that there’s no house tool — there’s a house fit. The team in San Mateo that picks the right one isn’t certified in any single platform; we’re optimizing for the workflow that’s still running, and still editable, long after we’ve handed it off. If you bring the workflow to a 30-minute call, we’ll run the residency-and-ownership test on it live and tell you which tool wins — even when the answer is the cheaper engagement for us.