n8n vs Python: I built the same automation both ways

We get asked "should we use n8n or just build it in Python?" constantly — so here's the honest answer from people who ship both. The short version: n8n wins on speed-to-prototype and readability for simple workflows; Python wins on complex logic, reliability, cost at scale, and ownership. Here's the real comparison, built from doing it both ways.

The honest comparison

We built the same automation — a multi-step order-processing flow with branching logic and a third-party integration — in both n8n and custom Python. Here's what each was actually like:

The pattern is clear: n8n wins the first week; Python wins the next twelve months.

Where n8n genuinely wins (and we recommend it)

We're not anti-n8n — we recommend it regularly. It's the right call when:

• The workflow is simple to moderate — a handful of steps, mostly linear.
• Non-developers need to read and tweak it themselves.
• You want a fast prototype to validate an idea before committing engineering time.
• Volume is low enough that execution-based cost never bites.
• The workflow isn't business-critical — if it breaks for an hour, nobody loses money.

If that's your situation, building custom code would be over-engineering. Use n8n and move on.

Where Python wins (and n8n starts to hurt)

Python becomes the right answer when:

• The logic is complex or stateful — branching, conditionals, "remember what happened last run."
• The workflow is business-critical and must not fail silently.
• Volume is high enough that per-execution pricing adds up.
• It needs real engineering: OCR, computer vision, heavy data processing, a custom integration with no pre-built node.
• It touches money or inventory and needs an audit trail, dry-run mode, and proper error handling (the same reasons we won't build purchase-order automation in no-code).
• You need to own it — version it, test it, hand it to any engineer, move it anywhere.

The "Code node" tell

Here's the moment that settles most decisions: when your n8n workflow grows a Code node (or several), you've conceded that the visual nodes can't do the job. Now you're writing JavaScript inside a constrained, execution-billed wrapper — with no proper version control, no local debugging, no test suite. That's strictly worse than writing the same logic in a real codebase. The Code node is n8n telling you you've outgrown it. (Same signal as reaching for "Code by Zapier".)

The total-cost reality

The cost comparison flips over time:

• Upfront: n8n is cheaper — minutes to stand up, especially self-hosted.
• Ongoing: execution-based pricing scales with your volume, self-hosting carries maintenance and upgrade burden, and complex n8n workflows quietly consume engineering hours to keep alive.
• Owned Python: higher upfront (a real build), then a fixed cost — no per-execution bill, and maintenance is normal version-controlled engineering.

For a high-volume or business-critical workflow, owned Python usually wins on total cost of ownership within the first year.

The take

n8n and Python aren't competitors so much as the right tools for different stages and stakes. Prototype in n8n; ship the simple stuff in n8n; but move anything complex, high-volume, business-critical, or money-touching into owned Python you can test, monitor, and keep. The decision tell is simple: the moment you're writing real code inside n8n, build it in a real codebase instead.

If you've got an n8n workflow that's turning into spaghetti — or you're deciding which way to build a new one — book a free 20-minute call. We'll tell you straight which tool fits, even when the answer is "stick with n8n."