Time to move on: n8n vs code for SaaS builders

Anthony Sidashin -

n8n is a no-code (low-code) automation platform—similar to Zapier but more technical—and it can be self-hosted. I love n8n (read my older detailed writeup about it): it makes you feel powerful on day one — drag a few nodes, connect an API, and suddenly you’ve automated a whole process. I've built a lot with it myself, including custom nodes, e.g. ScrapeNinja web scraping API integration node. I also maintain the Awesome n8n GitHub repo. For many non-technical indie builders and small teams, n8n feels like magic, and I see many agencies popping up that set up self-hosted n8n instances for their customers.
n8n took over Zapier in Google Trends and in people minds in 2024-2025 - it got this momentum mostly because its self-hosted distribution model is brilliant and serves as an awesome marketing channel; and because AI influencers all over Youtube used n8n as a platform for "Run your own AI chat bot in 5 min" educational videos.


But eventually, some of us hit the ceiling.

After building a few internal tools and SaaS prototypes with n8n, and after talking with lots of smart folks doing the same, I noticed a pattern: the moment you start calling it a “product” or "SaaS" rather than an “automation,” you’re probably past the point where n8n fits.
It is important to note that most of the points mentioned in this post are relevant for most of no-code and low-code platforms.
Here’s when that happens.

1. You Need a Real UX

n8n shines behind the scenes, not in front of customers. When launching products, once I think "would I use n8n here for MVP?" (By the way, MVP abbr stands for Minimum Viable Product) this one is the major blocker. More abbreviations for not-too-technical readers - UX is a shortcut for User Experience, UI stands for User Interface.

What n8n can do well in “UX land”:

  • Webhooks: it’s totally fine to keep n8n as your webhook receiver for internal flows or to glue services together. Treat it like a background worker with HTTP ingress. There is a trick to emulate HTML page output via n8n webhook but believe me, this does not end well for real products.
  • Forms: there is a built-in Form node for quick data capture, approvals, or small operational tools. To my taste, they are ugly, but they do the job.
  • Chat UI - n8n has custom chat UI which allows you to embed AI assistant into HTML page. I don't really like its UX but it works - and is great as a starter kit to experiment with AI agents!

For custom UIs, deploy separately — another no‑code tool or a code app.

Where it starts to hurt:

  • Once you’re building user dashboards, onboarding flows, sessions, roles/permissions, or anything that must feel polished, the visual workflow metaphor fights you. You’ll spend more time wiring webhooks and shaping JSON than building a focused UI.

At that stage, you’re not automating anymore — you’re engineering. A small code app (Next.js/Express/FastAPI) with a proper auth layer will be faster to iterate on and easier to test, version, and review.

If you never shipped real code to production, some news for you: modern frontend is a sticky mess. If you decide to go this route - I recommend to check shadcn UI which is definitely one of best UI frameworks available on the market right now. I also recommed to check out Lovable and Bolt which can mitigate your pain of getting started with UX; and then switch over to Claude Code or Cursor for editing.

2. Payments Are Serious

Subscriptions are the major thing which turns your workflows or code into real SaaS Product.

Most no-code workflows can handle simple Stripe calls, but as soon as you add subscription logic, idempotency keys, retries, proration, or multi-currency handling, things get fragile. The “Stripe node + webhook” combo works for MVPs, not for a real SaaS with thousands of transactions and audit requirements.

Stripe API is not what it used to be in 2010 - it's really big now, caters for different use cases, and it takes some time to figure out how it works.

In code, you can keep webhooks thin, enqueue events, process with a job queue, and attach observability. That level of control around billing, error handling, and audit trails is hard to replicate in a visual editor.

3. n8n Community License Does Not Fit SaaS

Recently, someone told me they were building a multi‑customer AI chatbot “on top of n8n” because “n8n developers are cheaper than regular devs.” That’s an MVP‑stage shortcut, not a production strategy. Many folks don’t realize the self‑hosted Community Edition license isn’t designed for building and selling a SaaS on top of n8n.

Will n8n find out if you violate the license? Don’t gamble. Do the right thing from the start—either budget for a commercial license or move the product logic to code.

Licensing context and links:

  • n8n is fair‑code, with the Sustainable Use License and a separate Enterprise License. Read: Sustainable Use License, Enterprise License, and the license explainer.
  • The SUL typically allows internal business use and consulting. Hosting n8n as the paid product or embedding it as a revenue‑generating feature requires a commercial agreement. n8n also offers an Embed program that, as of this writing, starts around $50,000/year.

Direct quote from the SUL: docs

Our license restricts use to "internal business purposes". In practice this means all use is allowed unless you are selling a product, service, or module in which the value derives entirely or substantially from n8n functionality.

Put simply: the moment you accept payments for a SaaS built on top of n8n, the Community Edition is not permitted.

Real‑world threads on multi‑tenant credentials and scale:

Takeaway: once you need per‑tenant secrets, scoped permissions, and contractual clarity—and you’re not budgeting for Enterprise/Embed—a small code backend with proper auth, a secrets manager, and per‑tenant queues is safer than stretching a single n8n instance.

4. You Need Versioning That Actually Works

Yes, workflows are JSON and you can export them. Some folks even automate export-to-Git from n8n itself or rely on built-in history. But merges and reviews remain painful compared to code.

Community anecdotes and constraints:

  • Users report syncing JSON to Git or using history; full Git integration is an enterprise feature. Reddit thread: Version control in n8n
  • Try merging two branches of a big workflow and you’ll see why text diffs, typed models, and PRs still win.

At any point, git diff beats “export workflow as JSON.” If your team depends on code review, CI, and tests, you’ve outgrown the visual editor.
Don't even get me started on modern AI coding tools which can review git history and commit code on your behalf... it's just another level and you should try it as soon as possible.

5. When Architecture Gets Complex

Once you’re orchestrating multiple APIs, queues, webhooks, and databases, n8n starts feeling like one giant script rather than a set of testable modules.

In code, you can separate layers, add tests, monitor performance, and scale horizontally. In n8n, complexity accumulates in a single visual flow, and operational concerns (retries, DLQs, idempotency, tracing) are harder to centralize.

The “47 nodes at 2 AM” anecdote shows up often for a reason—visual debt is real. If you need SLAs and clean rollback paths, code gives you the controls.

  • About the Code node: the Code node is excellent for quick JavaScript/Python snippets, but for non‑trivial logic you quickly run into dependency and runtime constraints.
  • Anecdote: I had a list of freelancers waiting for crypto payouts. Using n8n, I built a workflow that scanned Google Sheets and created payouts on the BEP‑20 (EVM‑compatible) blockchain, then wrote back transaction hashes or errors. I needed blockchain npm packages (like ethers), so I built a custom Docker image for n8n with those dependencies baked in. It worked—but managing deps, image updates, and security patches felt like running a bespoke backend rather than “no‑code”.
  • AI constraints: self‑hosted Code node doesn’t include AI enhancements. Writing code manually in a browser in 2025 is dated; AI assistance for the Code node is currently available to n8n Cloud users, not typical self‑hosted setups.
  • Signal to move: if you’re repeatedly adding external SDKs or complex libraries, move that logic to a small service with its own repo, dependencies, tests, and CI. Call it from n8n via HTTP/queues—or replace the flow with code entirely.

6. Performance Concerns

Performance in n8n is about the whole workflow lifecycle: triggers, network calls, payload sizes, execution storage, and scaling — not just the database.

  • Item fan‑out and node count:

    • Every node hop serializes/deserializes data and adds latency. Long chains with large items get slow and memory‑hungry.
    • Collapse trivial transforms into a single Code node where it reduces hops, or pre‑aggregate upstream so you pass fewer, smaller items.

  • Network chattiness and batching:

    • Loops that call external APIs per row are the classic bottleneck. Prefer bulk endpoints, batch inserts/updates, and rate‑aware concurrency.
    • Use Split In Batches to cap concurrency and add backoff; avoid tight polls when webhooks/events are available.

  • Database as a bottleneck - in a lot of cases, Google Sheets and Airtable are used as a database and while these products are awesome getting started; it is a very poor choice even for a medium load. Luckily, in 2025 n8n has finally launched data tables - built-in db which should perform way better compared to Google Sheets.

  • Scale the runner, not just the editor:

    • For sustained throughput, run Queue Mode with Redis and multiple workers (N8N_EXECUTIONS_MODE=queue, set worker concurrency) to process jobs in parallel.
    • Keep heavy workflows off the main/editor instance; scale workers horizontally and monitor queue depth/latency.

  • Triggers and external systems:

    • Polling (e.g., Google Sheets) adds unpredictable latency and hits quotas. Prefer webhooks and event sources where possible.
    • Sheets are fine for prototypes; for hot paths use a real datastore (PostgreSQL) and let n8n orchestrate, not store, the workload.

  • Data integrity under retries:

    • Per‑node retries can create duplicates. Use idempotency keys, unique constraints/UPSERTs downstream, or move critical write logic behind a small API that enforces exactly‑once semantics.

Bottom line: optimize workflows for fewer hops, smaller payloads, event‑driven triggers, and queue‑backed execution. Use Postgres (and/or a thin API) for durability and idempotency, and scale n8n with workers when throughput matters.

7. Deployment

One of n8n’s strongest advantages is skipping DevOps entirely: a single Docker container and you’re productive. For many teams, that’s perfect for internal automations and prototypes.

When DevOps becomes necessary:

  • Compliance and backups: scheduled DB/file backups, retention policies, and auditable change management for credentials and workflows.
  • High availability and scale: queue mode with Redis, multiple workers, external Postgres, and rolling upgrades; pin versions and test migrations.
  • Security and access: TLS, SSO, RBAC, network rules (VPC/egress allowlists), and secret management (e.g., HashiCorp Vault or AWS Secrets Manager).
  • Custom runtimes: Code node dependencies via a custom image; private registries; base image patching for CVEs.
  • Isolation: separate instances per environment/tenant; constrain cross‑tenant access by design.

If you’re regularly touching these concerns, you’ve crossed into “DevOps needed” territory—either budget time/skills for it or move core product logic to a service you can operate with standard SRE practices.

8. Observability

The built‑in Execution view is a highlight of n8n: you can open a run and see exactly which node failed and why. It’s excellent for ad‑hoc debugging — but sometimes it just doesn’t scale to concurrent millions of runs a day.

What to add for scale:

  • Centralized logs: ship container logs to Grafana Loki or the ELK Stack.
  • Metrics and dashboards: expose app and worker metrics to Prometheus and graph throughput, queue depth, execution latency (p95/p99), and error rate in Grafana.
  • Request visibility: keep reverse‑proxy (nginx/Traefik) access logs and forward them to the same sink; correlate with executionId to trace inputs to outcomes.
  • Retention and pruning: tune n8n’s execution data retention so the UI stays responsive and the DB doesn’t balloon; rely on your log/metrics backends for long‑term history.

If your ops questions sound like “which tenant’s runs are failing most this week?” or “why did queue latency spike?”, it’s time to treat n8n like any other production workload and invest in real logging and metrics.

Final Thoughts

n8n is perfect for what it was built for — automating processes, validating ideas, stitching APIs.
But when your project turns into a customer-facing product with real uptime, billing, and architecture needs, it’s time to graduate to code.

AI coding is already here and becoming software engineer to ship real, sophisticated SaaS products is possible for everyone. It will be painful, but the results are well worth it.

You don’t have to throw n8n away. Keep it for what it’s good at — internal automations, monitoring, glue work. But for your core product? Build it right.

Practical Migration Patterns

  • My best advice: get on a consulting call with adequate software engineer and describe your case. It's great if you have a working n8n workflow (Minimal Viable Product) and some customers at this stage, it simplifies things a lot!
  • My 2nd best advice: talk to ChatGPT and descibe what you are doing and your major pains. Ask it how your workflow could be gradually migrated to real code.

AI Tooling Makes Code Faster Than Clicks

If you’ve avoided code because you thought it would be slower than dragging nodes, that’s increasingly outdated.

  • Claude Code, Cursor, and Codex are insanely powerful for day‑to‑day engineering. They scaffold endpoints, write tests, refactor safely, and keep context across large changes.
  • Chat-driven coding is often more convenient than navigating a complex web UI. You can iterate on logic, add retries, or change data models with a single prompt and get runnable diffs.
  • These tools make the “rewrite” path viable: migrate a workflow to a small service with proper types, tests, and observability in hours rather than days.

My Recommendation

  • Keep n8n for internal automations and glue.
  • For customer-facing product logic, billing, and multi-tenant auth, use real code: clear modules, a queue, typed models, tests, and real version control.
  • Lean on AI coding tools (Claude Code, Cursor, Codex) to make the jump quickly and safely.