Time to move on: n8n vs code for SaaS

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 the 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.

n8n took over Zapier in Google Trends 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.

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:

Using n8n to Power a Scalable SaaS for AI Assistants – Self‑Hosted or Cloud?
Licensing clarifications from users and staff: Reddit

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.

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, move to a small service: 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.

My experience using n8n, from a developer perspective — tradeoffs and tips: https://pixeljets.com/blog/n8n/
Self-hosted is awesome — why I prefer self-hosting and how it applies to n8n deployments: https://pixeljets.com/blog/self-hosted-is-awesome/
Web scraping in n8n — practical patterns, selectors, proxies, and caveats: https://pixeljets.com/blog/web-scraping-in-n8n/