n8n vs custom code for AI automation: what to buy, what to build

Use a workflow engine like n8n when the automation is internal, low volume, and a failed run is an annoyance rather than a lost customer. Write custom code when the flow touches customers, runs thousands of times a day, needs real tests, or contains an LLM prompt you will keep tuning. The expensive mistake is not picking the wrong one. It is picking one and refusing to move when the signals say you have outgrown it.

Why this question comes up now

n8n has become the default answer when a founder says "we should automate this with AI". It is source-available under n8n's own Sustainable Use License, you can self-host it, and it ships nodes for most SaaS tools plus generic LLM and HTTP nodes. A non-engineer can build something that works in an afternoon. That is genuinely valuable, and it is also exactly why teams end up with a dozen fragile workflows nobody dares to touch.

The decision is less about n8n versus code and more about which parts of your automation deserve engineering discipline. We covered the conceptual split between agents and workflows in AI agents vs workflows. This post is the practical, money-on-the-table version.

What n8n is actually good at

Be honest about the strengths, because they are real:

• Speed to a first working version. Auth to Gmail, HubSpot, Slack, Notion, and Postgres is a dropdown, not a week of OAuth plumbing.
• Visibility for non-engineers. Ops and sales people can read a canvas. They cannot read a NestJS service.
• Cheap experiments. You can test whether an LLM step adds value before anyone writes a line of production code.
• Internal glue. "When a deal closes, create a folder, post in Slack, draft an onboarding email" is the sweet spot. Volume is low, failure is visible, and a human is nearby.

If your automation lives entirely in that list, stop reading and go build it in n8n. Hiring an agency for this is overkill.

Where it starts to hurt

The problems arrive gradually, and each one alone looks tolerable.

Prompts become untestable

An LLM prompt inside a node is a string in a database. There is no diff, no review, no eval suite. When output quality drifts, the only debugging tool is re-running the workflow and squinting at the result. Compare that with how the prompt in our own outreach engine lives: a version-controlled file, a fixed set of prospect websites as fixtures, and a strict output schema every drafted email has to satisfy. When we swapped the call to action from a calendar link to "reply YES", that was a one-line diff someone could review and roll back. When extraction accuracy drops, a test fails in CI instead of a salesperson noticing a week later. If you are serious about reliability, read deterministic guardrails for AI features. Almost none of that is ergonomic inside a visual editor.

Error handling is where visual tools lose

A real pipeline needs: retries with backoff, idempotency so a retry does not send the email twice, dead-letter handling for inputs the LLM cannot parse, and alerting when a scheduled run silently does not happen. Take the outreach engine again. A Firecrawl crawl can time out on a slow prospect site, the local LLM can return something that fails the output schema, and a retried run must not send a second cold email to the same company. Each of these is possible in n8n. Each one is also a tangle of extra nodes and branches that makes the canvas unreadable, which defeats the one advantage the canvas had. In code, these are a few well-understood patterns: a retry wrapper around the crawl, a schema check that routes failures to a review queue, and a per-company sent flag checked before anything goes out.

Volume changes the economics

At ten runs a day, nobody cares how a workflow is executed. At ten thousand, you care about concurrency, queue depth, and how execution logs are stored and pruned. n8n can be scaled in queue mode, but at that point you are operating infrastructure anyway, and you have taken on the ops cost of a workflow engine without getting the testability of code. You might as well own the code.

Ownership and lock-in

n8n's license is permissive for internal use but restricts offering it as a hosted service to others. If the automation is part of what you sell, check the license with someone who reads licenses, and assume the logic should live in code you fully own. The same goes for anything with compliance exposure: audit logs, data residency, and access control are easier to prove when the flow is a service you control end to end.

A concrete example from our own stack

We run our outreach engine on custom code, not a workflow tool, and the reason is instructive. The pipeline crawls each prospect's website with a self-hosted Firecrawl instance, hands the content to a local LLM, and produces one tailored email per company. The first instinct was a multi-step chain: one call to extract facts, another to pick an angle, another to draft. We tried it and also tried a single call that extracts the facts and drafts the email together, with a strict output schema. The single-call version won on both cost and quality. We go deeper on why in single call vs agent chains.

The relevant point here: discovering that took dozens of controlled runs against the same fixture set, comparing outputs side by side, and changing one variable at a time. That is a test harness, and it is trivial in a TypeScript repo. It is miserable in a drag-and-drop canvas. Had we built the engine in n8n, we would probably still be running the slower, more expensive chain because the cost of experimenting would have been too high.

The second lesson from the same tool: the biggest lift in reply rate came from a copy change, not a model change. Moving the call to action from a calendar link to a soft "reply YES" consistently got more responses from cold prospects. That change took one line in a version-controlled prompt. Being able to make and measure it cheaply is the whole argument for code when the flow matters to revenue.

A decision framework you can apply in ten minutes

Score each automation on these five questions. Three or more "yes" answers means build it in code.

1. Does a customer see the output directly? Emails, WhatsApp replies, quotes, support answers.
2. Will it run more than a few hundred times a day within a year?
3. Does it contain an LLM step whose quality you will keep tuning? Extraction, classification, drafting.
4. Does a failed or duplicated run cost money or trust? Double-charging, double-sending, missed leads.
5. Does it touch regulated or sensitive data? Health, finance, government, personal data of EU or Gulf residents.

Zero or one "yes": n8n, built by whoever owns the process. Two: n8n for the orchestration, but keep prompts and business rules in a small code service that n8n calls over HTTP. This hybrid is underrated. It keeps the readable canvas for ops while giving engineering a tested, versioned core. Three or more: code, with n8n at most as a trigger source.

What the hybrid looks like in practice

• A small NestJS or Next.js API with one endpoint per capability: extract-company-facts, draft-email, qualify-lead.
• Prompts, Zod schemas for structured output, and fixtures live in the repo and run in CI.
• n8n handles the boring edges: cron triggers, pulling from the CRM, posting to Slack.
• When volume or reliability requirements grow, you replace the n8n orchestration with a queue. Nothing about the logic changes.

This also makes the hiring question easier. You can get the n8n wiring done by an ops person or a freelancer. You bring in engineers for the service, which is the part that needs tests and a maintenance plan. For what that ongoing cost realistically looks like, see the real maintenance cost of an AI agent.

What to ask whoever you hire

• "Which parts of this would you deliberately keep out of n8n, and why?" A good answer names prompts, retries, and idempotency.
• "How will we test a prompt change before it goes live?" If the answer is "run the workflow and check", keep looking.
• "What happens when the LLM returns garbage at 3am?" You want to hear dead-letter queue, alert, and a human review step.
• "Who owns the prompts and schemas, and where do they live?" The answer should be "you, in your repo".

The short version

n8n is a great prototyping tool and a fine home for internal glue. It is a poor home for the AI logic that drives revenue, because that logic needs experiments, tests, and version history, and visual tools make all three expensive. Prototype in n8n, prove the value, then move the core into code you own. If you want help drawing that line for your specific stack, let's talk.