n8n, Zapier, or Custom Build: Where the Line Is

Start with Zapier. Here is the line where that stops being true.

If you are automating something for the first time, use an off-the-shelf tool and do not call anyone. Zapier, Make or n8n will do it this week for the price of a lunch, and a supplier who tells you otherwise before asking what the workflow is has told you something about their sales process. The line where no-code automation stops being the right answer is not a feeling about sophistication. It is four measurable conditions: how many times a month it runs, whether a failed run has to be retried and reconciled rather than merely reported, whether the data is allowed to sit in someone else’s cloud, and whether the branching still fits on one screen. Cross one of them and you have a decision to make. Cross two and a custom build is cheaper, not just better.

What Zapier and n8n genuinely do well

Engineers understate this because the tools compete with billable work. Three things they do better than a custom build, and the first one is the important one.

They find the specification for you. Building the workflow in an afternoon shows you what it actually needs to do, including the four edge cases nobody mentioned in the meeting. That knowledge is worth more than the automation. If you later commission a custom build, arriving with a working prototype and six months of run history removes most of the discovery cost, and it is the single cheapest way to make a supplier quote accurately.

They cover the long tail nothing else will. The alert that posts to one channel, the monthly export somebody used to do by hand, the form that has to create a task in two systems. Nobody is going to write custom code for a workflow that runs forty times a month, and a good automation stack has dozens of these. They should stay where they are permanently.

The connector library is a genuine asset. Hundreds of pre-built integrations, maintained by someone else, updated when the upstream API changes. Rebuilding one of those is a day of work you would rather not repeat every time a vendor ships a new API version.

A related question, which this article is not about, is no-code platforms for building the AI models themselves rather than for connecting systems. We covered where that hits its own wall in custom AI without heavy coding. The conclusions rhyme, and the tools are different.

Where no-code automation breaks, specifically

Error handling that has to reconcile, not just alert. This is the first threshold most companies cross and the one they notice last. A no-code tool tells you a run failed. What it does not do well is guarantee the work eventually happened: retry with backoff, detect the duplicate created by the first half-successful attempt, hold a queue while an upstream system is down, and let somebody see at a glance which of last week’s two thousand records did not make it. If a missed run costs money or breaks a legal obligation, you need reconciliation, and reconciliation is where custom code starts earning.

Logic that no longer fits on one screen. Branching is fine. Branching inside branching, with a shared step that three paths call and a condition somebody added in March that nobody can explain, is a program written in a medium with no version control worth the name, no tests, and no way to review a change before it goes live. When a visual workflow needs scrolling in two directions, it has become code, and it deserves the tooling code gets.

Data that is not allowed to be there. Special-category personal data, client-confidential documents, anything with a residency requirement. A hosted automation tool is a processor in your chain, in whatever region it operates, and your data-protection assessment has to cover it. This is the threshold with the cleanest answer of the four, because n8n can be self-hosted on your own infrastructure while most competitors cannot, so the migration is often to the same tool in a different place rather than to a custom build at all. The wider question of which deployment path a regulated workload can take is in GDPR and LLMs.

Volume, eventually. Per-task pricing is generous at the bottom and unkind at the top, which is the whole commercial model. It is genuinely the last threshold rather than the first, and most companies quote it as their reason when one of the other three is the real one.

What it costs at 100, 10,000 and a million runs a month

Tier names and prices move every year, so treat the shape as the durable part and check the current numbers yourself. The shape does not change: a hosted tool bills roughly in proportion to runs, while a custom automation build is a large fixed cost followed by a small one.

• Around 100 runs a month. A free or entry tier covers it, so the tool costs tens of euros a year and your own time is the real expense. A custom build here is indefensible at any price. Stay put, and stay put permanently.
• Around 10,000 runs a month. You are on a mid tier, which across the main vendors lands in the low hundreds of euros a month, so call it a few thousand a year. A custom replacement in the €8,000 to €18,000 bracket pays back on licence savings alone in something like three to five years, which is not a good enough reason on its own. If you migrate at this volume, migrate because of reliability or compliance and be honest that the cost case is thin.
• Around a million runs a month. Per-task pricing now dominates the conversation and the annual figure is comparable to the entire build. A self-hosted n8n on a modest server, or purpose-written code on a queue, costs a fraction of it. Here the licence line alone justifies the work, and the reliability argument comes free with it.

The useful conclusion sits in the middle band. Between roughly a hundred and a hundred thousand runs a month, cost is almost never the reason to leave. The reason is that a failure now matters, and you can read the full price ranges for a custom build against your own numbers before deciding.

Migrate the hot path, keep the tail

The expensive mistake is treating this as a replacement project. You have thirty automations, four of them matter, and turning all thirty into a custom automation build is six months of work to solve a problem that lives in four. Move the four. Leave the rest exactly where they are, and let the two systems coexist for years, because they will anyway.

The LexAlert legislative monitoring platform is a fair picture of what the hot path looks like when it has crossed the line. It ingests from three official gazettes, deduplicates against everything it has already seen, summarises against a firm’s active matters and runs unattended every three hours. Every part of that is a threshold: the deduplication is state a connector cannot hold, a missed gazette is a professional risk rather than an inconvenience, and the routing logic has more branches than a canvas can show. A no-code tool would have found the specification well and then failed at the reconciliation. Our other case studies and the capabilities page show the same division of labour.

One rule for the move: keep the tool running in parallel for two weeks and compare outputs record by record. Every migration of this kind surfaces at least one behaviour the old workflow had that nobody documented, usually a quiet exception somebody added at 6pm two years ago.

Three cases where the honest answer is to keep the subscription

Nothing has broken yet. If you cannot name a specific failure that cost you something, you are buying insurance against an imagined risk with real money. Wait for the failure. It is cheap information and it arrives on its own.

The workflow will change again next quarter. A process still being invented belongs in a tool where a non-engineer can change it on a Tuesday. Custom code is the right medium for a settled process, and premature hardening of a moving one just relocates the churn to a developer queue.

Only the volume threshold applies, and only just. If your licence bill is annoying but the workflow is reliable and compliant, the cheapest move is usually a plan change or a self-hosted instance of the same tool. That advice costs us the project and it is the correct advice, which is also the general shape of where automation actually creates value: the return comes from the process being right, not from the technology being bespoke.