n8n vs. Custom AI AutomationA decision framework that holds up in production

"Should we use n8n or build custom?" is rarely the right framing. The real question is: which parts of this problem fit a visual workflow builder, and which parts need code? Most production systems end up with both, and the trick is knowing where to draw the line.

This post lays out the criteria we use when scoping AI software development and automation work with clients. The goal is not to sell you one tool. The goal is to spend your budget where it actually earns its keep.

n8n is excellent when the workflow has these properties:

• Deterministic main path. Most steps are "call this API, transform this JSON, write to this sheet." The AI step is optional flavour on top.
• Low to medium volume. A few hundred to a few thousand runs a day is n8n's sweet spot. The self-hosted version scales higher with care.
• Short-lived state. Each run is mostly self-contained; there's no long-running conversation or multi-hour job.
• Non-engineering owners. The people maintaining the workflow are ops, RevOps, or marketing — not developers. A visual builder they can read and edit is worth a lot.
• Fast iteration. You need to ship, measure, and modify weekly. n8n collapses the cost per change.

A great example: "when a lead fills the website form, enrich via Clearbit, classify the intent with an LLM, route to the right Slack channel, and create a deal in the CRM." That's n8n's home turf. Building it in custom code is overkill — and harder to hand off to a non-engineer.

Custom code wins when the workflow has any of these:

• Non-trivial state. Long conversations, multi-step agents, jobs that take minutes to hours and need checkpoints — visual builders strain here. Code expresses it naturally.
• Complex branching. If the graph has more than ~15 nodes and multiple loops, n8n starts fighting you. Code is easier to read past that point.
• Strict reliability SLAs. Retries with exponential backoff, idempotency keys, distributed locks, graceful degradation — all doable in n8n but cheaper in code.
• Typed contracts with the rest of your product. If this workflow is actually part of the product your users interact with (not an ops tool), you want the same typing, testing, and deployment discipline you apply to the app.
• AI-first logic. Agentic workflows with dynamic tool selection, retrieval, and RAG over business documents are cleaner in code. You can still call them from n8n, but the AI core wants to live in a codebase.
• Compliance and data residency. If the workflow touches regulated data, you often need full control of where each step runs and what it logs. Custom code gives you that without negotiating with a platform.

n8n feels cheaper because the first workflow ships in days. The trap is what happens after:

• Workflow 2 takes almost as long as workflow 1, because you can't share code.
• Workflow 10 is a maze of "sub-workflows" that nobody remembers.
• Every provider upgrade risks breaking multiple flows.
• Observability is per-node, not per-product — hard to build a cohesive view.

Custom code has the opposite profile. Workflow 1 is expensive because you're paying to set up the foundations (deployment, logging, retries, eval). Workflow 2, 3, 4 ship in a fraction of the time because they reuse those foundations. By the time you hit workflow 10, the cost per new workflow is lower than in n8n.

Rough rule of thumb: under ~3 serious workflows, pick the visual builder. Over that, invest in a codebase.

Almost every production system we ship mixes both. A typical shape:

• n8n for the edges. Third-party integrations, webhook receivers, scheduled triggers, ops-level glue. Anything the ops team needs to own and change without engineering.
• Custom services for the core. The AI logic — prompts, retrieval, tool use, evaluation — lives in a small Python or TypeScript service with proper tests, observability, and CI/CD.
• Clean seam. n8n calls the custom service via HTTP with a typed payload. The custom service never calls n8n back; it returns a response or writes to a shared queue/database.

This split respects who owns what. The ops team can tune the integrations without breaking the AI core. The engineering team can iterate on models and prompts without breaking ops. Bugs have obvious homes.

The same framework applies. Zapier is heavier on SaaS integrations and lighter on self-hosted control. Make is the most expressive visual builder but not the fastest for developer handoff. None of them changes the underlying question: is the workflow simple enough that a visual tool wins?

You're probably due to move the AI core into custom code if:

• You've split a workflow into three "sub-workflows" to fit the UI, and still can't see what it does.
• Debugging means opening 20 node outputs one at a time.
• You've written JavaScript in more than half the nodes.
• Incident response regularly involves re-running a workflow partway through because the AI step changed.
• You have the same retrieval logic duplicated in four flows.

Any two of the above and it's time. You don't have to rewrite everything — just lift the AI core into a service, keep n8n as the ops surface.

If you're early and the scope is small, ship on n8n or similar. Measure the real volumes, the real failure modes, and the real maintenance load. Keep a list of workflows you've built and a note on each one's pain.

When the pain on one workflow (or across the set) crosses the line, scope the custom service. We usually:

1. Audit the existing n8n or Zapier workflows and classify them: stay, migrate, or retire.
2. Design the custom core — typically a small service, a vector database, and eval.
3. Migrate the one or two highest-value workflows first, keeping n8n as the calling layer.
4. Only rebuild the rest once the pattern is proven.

n8n and custom AI automation are not rivals — they're a spectrum, and the right answer for your business is almost always "both, with a clear seam."

If you'd like help mapping your current automation and deciding which parts deserve custom code, our AI software development service covers this kind of work. Read about agentic AI workflows for more context, or get in touch with a description of the workflow you want to improve.