Keep most automations on n8n: it is fast to build, cheap to run and readable by non-engineers. Move a workflow to custom code when a failure halfway through is expensive, when it needs per-record state across runs, when changes need tests before they ship, when it has grown past about thirty nodes, when the AI step has become the product, or when volume and audit demands outgrow the platform. Graduate one step at a time by having n8n call a small tested service, migrate the riskiest workflow first using past runs as test cases, and shadow-run before cutting over.
Is n8n or custom code better for business automation?
For most automations, n8n. It is quick to build in, cheap to run and readable by people who are not full-time engineers, and we recommend it on client work regularly. Custom code is better for a smaller set of workflows: the ones where a failure halfway through is expensive, where the workflow has to remember things between runs, or where nobody can safely change it any more.
So the useful question is not which is better, but when a particular workflow should graduate. Most businesses that automate seriously end up with both: n8n for the many simple flows, code for the few that carry real weight. If you are still choosing a platform in the first place, start with n8n vs Zapier.
When should an n8n workflow move to custom code?
When the cost of it going wrong, or of changing it, has outgrown the convenience of the canvas. Six signs, any one of which is worth a conversation:
1. A failure halfway through leaves a mess
If step seven fails after steps one to six have created records, sent emails or moved money, you need transactions, idempotency keys and a dead-letter queue so a retry does not repeat the first six steps. n8n has error workflows and retries, but this kind of guarantee is much easier to build and prove in code.
2. It needs to remember what happened last time
A workflow that tracks per-record state across runs - what was sent to whom, which invoices were matched, where each case is up to - has become an application with a database. Storing that state in spreadsheets or workflow static data works until it does not.
3. Changes need tests before they ship
There is no good way to unit-test a visual workflow. When a small edit has broken something important more than once, you need tests that run before a change goes live, and that means code.
4. The canvas has passed about thirty nodes
Past roughly thirty nodes, nobody can hold the workflow in their head. The visual editor stops being an advantage and becomes the reason changes are slow and risky.
5. The AI part has become the product
An AI step that classifies or extracts fits well in a node. When the AI is the point - it needs an evaluation set, retries that tell a rate limit from a bad prompt, cost control per request and a choice of model per step - it needs to be engineered as software. That is the case we are asked about most.
6. Volume or audit requirements have grown
Very high execution volumes, strict audit trails of every decision, or compliance reviews that ask how a change was tested all push towards code that can be versioned, reviewed and monitored like any other system.
What does custom code give you that n8n doesn't?
| n8n | Custom code | |
|---|---|---|
| Speed to first version | Fast | Slower |
| Who can change it | Technical staff comfortable with logic and JSON | Engineers |
| Error handling | Error workflows and retries | Transactions, idempotency, queues, replay, dead-letter |
| State across runs | Workable for small amounts | A proper database |
| Testing | Limited | Unit, integration and regression tests |
| Code review and versioning | Workflow exports and history | Pull requests and full history |
| AI evaluation and cost control | Basic | Evaluation sets, per-step model choice, cost per request |
| Running cost | Cloud plan, or roughly $14-150 a month self-hosted plus your time | Hosting plus engineering time |
The running cost figures for n8n are worked through in what n8n actually costs. Custom code is rarely cheaper to run; it is cheaper to trust.
Can you keep n8n and move only part of a workflow to code?
Yes, and it is often the best first step. Keep n8n as the orchestrator - triggers, scheduling, the simple connections it does well - and move the one step that needs engineering into a small service that n8n calls over HTTP. The difficult part gets tests, proper error handling and monitoring; everything else stays where your team can see and change it.
Over time, some workflows end up entirely in code and others never leave n8n. Graduation can happen one step at a time, which keeps the risk of each change small.
How do you move an automation from n8n to custom code safely?
- 01
Inventory and rank
List the workflows and score each on how much a failure costs and how often it needs changing. Move the top one or two, not everything.
- 02
Write down what it really does
Including the edge cases someone patched in a node at 6pm on a Friday. The canvas is the only specification, so read it properly.
- 03
Build with tests from real runs
Use past executions as test cases. The new version must produce the same results on them, plus the failure handling the old one lacked.
- 04
Run both in parallel, then cut over
Shadow-run the code beside the workflow and compare outputs. Switch when they agree, and keep the old workflow disabled, not deleted, for a while.
What should a custom-code replacement for an n8n workflow include?
If you are paying to move a workflow out of n8n, the replacement should fix the reasons you moved it, not just reproduce the canvas in another language. Check that it has:
- Idempotent steps, so a retry after a failure never sends the same email or creates the same record twice.
- A queue with retries and a dead-letter store, so failed items wait to be replayed rather than disappearing.
- Tests built from real past runs, run automatically before every change.
- Logging and alerts that tell a named person when something fails, with enough detail to replay it.
- For AI steps, an evaluation set, per-step model choice and a record of cost per run.
- A short runbook and documentation, so the workflow does not depend on whoever wrote it.
It should also live in your repository and your cloud account, with keys in your name. A rebuild that moves the workflow from a canvas you can see into a system only the supplier can change has made the original problem worse. Our guide to auditing an AI system someone else built covers how to check this at handover.
How much does it cost to rebuild an n8n workflow in custom code?
With us, rebuilding a single automated process starts at $4,500, and a suite covering one workflow end to end is $4,500 to $7,500, delivered in four to six weeks. Running costs for most automation at moderate volume are $60 to $250 a month on your own accounts. Our AI automation page sets out what a build includes. If the workflow needs to plan its own steps rather than follow a fixed route, that is agent development instead.
When should you stay on n8n?
- The workflow is short, readable, and nobody is afraid to change it.
- A failure is easy to notice and cheap to fix by hand.
- The people who maintain it are not engineers, and you would rather keep it that way.
- None of the six signs above apply yet.
If that describes your workflow, keep it on n8n. Rebuilding something that works, in a form fewer people can change, is not an improvement.
When should you move from n8n to custom code?
Keep most automations on n8n. Move a workflow to custom code when a failure halfway through is expensive, when it needs state across runs, when changes need tests, when it has grown past about thirty nodes, when the AI step has become the product, or when volume and audit demands outgrow the platform. Graduate one step at a time by calling a small service from n8n, migrate the riskiest workflow first, and shadow-run before you cut over.