n8n vs Custom Code: The Four Tripwires That Tell You When to Move Off

Move a workflow off n8n when any one of four thresholds trips: more than roughly eight branches in a single flow; state that has to survive across more than three steps; a monthly platform bill that climbs past what a small server costs; or a wrong result that reports success. If none of those is true, stay where you are — the migration is a cost, not a virtue.

Notice what is not on that list: what the workflow does. The circulating advice — 'n8n for ops, Python for product' — sorts by domain, and it is wrong in both directions. It pushes teams to rewrite a clean, working operations workflow just because it touches a database, and it lets a fragile, business-critical automation stay in a visual editor because it is 'just ops.' The real boundary is who has to debug the thing at 2am and whether its failures are loud or silent. The rest of this piece replaces the slogan with the four tripwires and shows the numbers behind each one.

Before latency or determinism, the axis that decides your bill is what the platform counts. n8n bills one execution per workflow run, no matter how many steps are inside it — its pricing page is explicit that 'an execution is a single run of your entire workflow.' Zapier bills one task per completed action step; the trigger is free, every action after it counts. Make bills per operation, where most actions cost one credit and a single run can burn anywhere from two to thousands (all three vendor pricing pages, retrieved 9 July 2026).

That single difference reorders everything. A ten-step workflow run is one billable unit on n8n and roughly ten on Zapier or Make. So a comparison that lines up '10,000 runs' across all three is quietly comparing 10,000 executions against about 100,000 tasks against about 100,000 operations. Any table that shows a flat monthly price without fixing your step count is measuring the wrong thing.

The axes worth tabulating are these: billing unit (execution vs task vs operation); entry price and included volume; determinism, meaning does the same input always give the same output; debuggability, meaning can you replay a single failed run with its exact data; who can modify it, an ops person in a browser or an engineer with a repo; and failure mode, loud or silent. Price and 'number of integrations' are the two axes vendors lead with, and the two that decide the least.

Hold the workflow at ten action steps and walk it up three volumes. All figures below were retrieved on 9 July 2026 from each vendor's public pricing page, and are an illustrative model, not a quote.

At 10,000 runs a month (about 100,000 action-steps): n8n counts 10,000 executions, which sits inside its Pro plan at EUR 50/month. Zapier counts about 100,000 tasks; its Professional plan starts at USD 19.99/month billed annually for just 750 tasks and scales up in tiers to two million, so 100,000 tasks is many tiers up — Zapier does not publish those higher price points as a flat table, so you must read your own off Zapier's pricing page. Make's Core plan is USD 9/month for 10,000 operations; 100,000 operations is well beyond it and priced in larger bundles.

At 100,000 and 1,000,000 runs the cloud picture inverts. n8n Cloud's Business plan tops out at 40,000 executions for EUR 667/month, so past that you are on Enterprise or you self-host. And self-hosting is the number that reframes the whole decision: the n8n Community Edition is free with unlimited executions — you pay only for the server, roughly EUR 4-12 (about USD 5-15) a month for a VPS, more if you add managed PostgreSQL. What you actually take on is maintenance: Docker, TLS, backups, monitoring, and patching become yours. At a million runs, the platform question stops being 'which plan' and becomes 'do we host it ourselves,' which is a far smaller step than a full rewrite into code.

Your step count, run volume, and connector mix will move every one of these figures — this is an illustrative calculation built from published entry prices, and your inputs will differ. The point is the shape, not the exact dollar: per-task billing punishes step count, per-execution billing punishes nothing until you outrun the cloud tier, and self-hosting removes the volume ceiling in exchange for owning the box.

Most of what runs in n8n should never become code. A twelve-node workflow that moves a form submission into a CRM, posts to Slack, and files a row in a sheet is doing integration glue — and the low-code tool's entire value is that the connectors, auth refresh, and retries are already written and maintained by someone else. Rewriting it into a repo means you now own OAuth token rotation for six SaaS APIs that used to be a checkbox.

Rewrite is a net loss when the workflow is mostly connectors and little logic, when the person who maintains it is not an engineer, and when a failure is loud — it throws, someone gets paged, nothing corrupts silently. Those three conditions together describe the majority of automations, and they are exactly the ones agencies talk teams into rewriting because a single node looked ugly. An ugly node is not a tripwire. Reach for the escape hatches first: a Code node for the awkward transformation, a sub-workflow for the repeated branch. A working 12-node workflow rewritten into a service you now have to deploy, monitor, and staff is usually a downgrade wearing an upgrade's clothes.

When a tripwire does trip, the default move — 'rewrite the workflow as a service' — is the expensive one and rarely the right first step. The cheaper path leaves the boundary where it is and moves only the part that hurts. Extract the workflow's logic — the branching, the calculation, the decision — into a single function with tests, deploy it behind one HTTP endpoint, and have the n8n workflow call it. The trigger stays in n8n. The connectors stay in n8n. Only the brittle logic moves.

Concretely: an eight-branch pricing workflow collapses into one n8n HTTP Request node pointing at your /price endpoint, and the eight branches become a tested function in a repo where a wrong result fails a unit test instead of a customer's invoice. You have kept the low-code trigger and connectors, put the risky part under version control and CI, and you can move the boundary further later — or never, if that was all that hurt. This is also how you keep one system debuggable by both an ops person and an engineer at the same time, instead of forcing a full handoff the day you cross a threshold.

Adding one LLM node quietly breaks three assumptions the rest of your workflow was built on. The run stops being deterministic — the same input can now produce different output, so a test that passed yesterday guarantees nothing today. Retries stop being safe — re-running a failed step that already sent an email or charged a card, previously idempotent, now also re-rolls the model's answer. And the failure mode flips from loud to silent, because a plausible-but-wrong LLM output looks exactly like a correct one.

That is the point where a workflow becomes a system that needs evals — a fixed set of inputs with expected-range outputs you run on every change — an audit trail of prompts and responses, and guardrails on what the model is allowed to trigger. None of that fits in a node's configuration panel. If your automation has grown an LLM step and you are no longer sure whether it is quietly wrong, that is the natural handoff to engineering. Visperah Tech's AI agents work exists for exactly this transition, and the run-cost economics of an LLM in the loop are a topic of their own.

The single best reason to move to code is invisible in every feature comparison on the internet: a silent failure — an automation that reports success while producing a wrong result. A workflow that returns a clean 200 on every run while writing the wrong tax rate to invoices has been 'green' for weeks. No dashboard flags it, because from the platform's point of view nothing failed. This, not branch count or bill size, is the failure the tripwires are really guarding against.

Detect it before your customers do. Work through this checklist: Does every run assert something about its output, not merely that the step returned? Does a wrong-but-well-formed result — an empty list, a null price, a silent default-fallback value — raise an alert, or does it pass as success? Can you replay a specific run from last Tuesday with its exact input data? Is there a reconciliation step, a nightly count that the number of records processed equals the number received? If you answered no to any of these and the workflow touches money, data, or anything a human trusts unread, that is your reason to move it — regardless of how few branches it has.

Run your busiest workflow through four questions. One: does it have more than roughly eight branches in a single flow? Two: does it carry state across more than three steps? Three: is the monthly bill climbing past what a small server would cost, and rising with volume? Four: can it produce a wrong result that reports success? Count your yeses.

Zero yeses: do nothing. Leave it in n8n, add a Code node if one transformation is ugly, and spend the migration budget elsewhere — this is the branch most audits skip and most teams actually need. One yes, on cost: try self-hosting before you rewrite, because unlimited executions on your own server may be the entire fix. One yes, on the silent-failure question: extract that logic into a tested function this quarter, even if nothing else moves. Two or more, especially with an LLM node in the flow: you have crossed into system territory, and the trigger-stays, logic-moves path is your cheapest route across.

Visperah Tech runs this migration as scoped engagements rather than rip-and-replace: map the tripwires, pull the risky logic into a tested service, and leave the low-code trigger and connectors doing what they are already good at. If a workflow of yours is throwing more than it should — or worse, has gone suspiciously quiet — that is a good afternoon to have the conversation.