3 min read
The real question is not which tool
It is which constraint you are going to hit first. Every automation platform is cheap until you hit its particular wall, and the walls are in different places. Choosing well means predicting which one you will reach.
There are three walls worth planning around: per-task pricing, data residency, and logic complexity.
Zapier: fastest to value, first to get expensive
Zapier's strength is genuine and often underrated by engineers: someone who is not a developer can connect two systems this afternoon, with no infrastructure and no deployment. For a workflow that fires a few hundred times a month, that is almost always the right answer, and building it yourself would be a poor use of money.
The wall is volume. Zapier charges per task, so cost scales with how often the automation runs. A workflow that fires ten times a day is trivial; the same workflow at ten thousand times a day is a budget line item. The break-even is not a fixed number — it depends on your plan and how many steps each run consumes — but the shape is reliable: the more successful the automation, the more it costs, forever.
n8n: the middle ground, and where it actually wins
n8n covers the same connect-two-systems ground but can be self-hosted, which changes two things.
The first is cost shape: self-hosted, you pay for a server rather than per task, so volume stops being the thing that scales your bill. The second matters more in regulated work — the data never leaves infrastructure you control. For clients whose records cannot go to a third-party SaaS, that is not a preference, it is the requirement that decides the tool.
n8n also handles genuinely complex flows — branching, loops, custom code nodes — further than a purely visual builder usually goes. The wall here is operational: it is your server now. Someone has to patch it, back it up, and notice when it stops. That is real ongoing work, and it is the cost people forget when comparing a self-hosted tool to a hosted one.
Custom: when the workflow is the product
Custom code is the right answer less often than developers think, and more often than platform vendors admit.
The honest signals that you have outgrown a workflow tool: the logic no longer fits on one screen; you are writing code inside function nodes to work around the visual model; you need real tests because a silent failure is expensive; or the automation has become a product feature your customers depend on rather than an internal convenience.
The pattern we see most is not replacement but augmentation. On a document-extraction build, the client already had a working n8n pipeline; the sensible move was not to rip it out but to plug a purpose-built extraction service into it, so the orchestration stayed where the team could see it and only the hard part became custom.
How to choose, briefly
Answer these in order and the choice usually makes itself.
- Can the data legally and contractually leave your infrastructure? If no — self-hosted n8n or custom, and the decision is made.
- How many times a month will this run? Under a few thousand, hosted is almost certainly cheaper than the engineering time to avoid it.
- Would a silent failure cost real money? If yes, you need retries, alerting and logging — available in all three, but you must actually build them.
- Does the logic fit on one screen? If it stopped fitting, you are already paying the cost of custom without the benefits.
- Who maintains this in a year? Self-hosting is a commitment, not a one-off saving.
The failure mode nobody plans for
Whichever you pick, the thing that actually goes wrong is not the tool. It is an automation that breaks quietly and keeps reporting success — dropping records for weeks before anyone notices, usually at month-end when the numbers do not reconcile.
Retries, failure alerting and a log you can query are worth more than the platform choice. A workflow that fails loudly on the cheapest tool beats a silent one on the most expensive.