n8n is the automation tool Tandem uses most. More than 20 engagements have run through it, in small and mid-sized companies, and some of those flows have been live for over two years.
My verdict fits in three sentences. n8n remains the best place to run business logic that has to survive without supervision. It becomes a trap when a team asks it to replace a real product, a document base or an autonomous agent. And the painful invoice stays the maintenance, well ahead of the subscription.
What n8n does better than other automation tools
The real strength of n8n shows the day an automation falls over. You open the failed execution, you see the node that broke, the data it received and the data it returned. You replay it. That visual reading saves hours of investigation, and it explains why we keep n8n even when part of the processing lives elsewhere.
The catalogue has also grown a lot. Its official catalogue passes 2,000 integrations in October 2026. Many articles still quote a few hundred connectors, which gives a false picture of what the tool covers today.
Control is the other reason n8n holds up over time. Almost every automation we ship is deterministic, including the ones that call a language model along the way. The flow always follows the same path, only the input data changes. A company wants to know what is going to happen, and n8n makes that path visible on screen. The business owner who signs off on the process reads the same diagram as the person who built it.
On our engagements, the flows that last are rarely spectacular. Sorting inbound requests, chasing unpaid invoices, preparing meetings, syncing a form with a CRM. Those are the ones still running two years later, because their business logic barely moves.
One last point that matters inside companies, credentials stay in the platform. A team can build a flow without ever handling a plain-text API key. If you need the basics first, our n8n guide starts from scratch, and n8n against Make and Zapier covers the choice between the three.
Why a workflow that works in a demo breaks in production
This is the gap I see most often. A flow built in one afternoon runs perfectly in front of the client. Three weeks later it has stopped, and nobody noticed. The cause almost never sits in the business logic.
The vendor documentation on error handling states that the error workflow is set in each individual workflow's settings. In other words, a new workflow ships with no alerting until somebody attaches one. On an instance hosting thirty flows, a single oversight is enough to lose visibility on a whole chain.
The most frequent technical failure on our projects remains memory. One large file loaded whole into a code step, and the instance goes down.
The vendor documents this plainly. Its page on memory errors states that n8n does not restrict the amount of data each node can fetch and process, and that the Code node significantly increases memory consumption. The remedy fits in one sentence. Split the work into sub-workflows that return only the result the parent flow needs.
What the entry plan does not put forward
The pricing page, checked in October 2026, lists the Starter plan at 20 euros a month billed annually. The headline figure is the execution count. The limits that actually make or break a project sit elsewhere in the table.
The Pro plan raises the maximum duration to 40 minutes and history to five days. That is the first tier genuinely usable by a company that depends on its flows. The Business plan is announced as self-hosted only.
The subscription is the small line, though. What really costs is the build time, then the maintenance hours when an API changes format. We broke that split down in the real cost of an n8n project, and n8n free or paid covers the self-hosting question.
What breaks when volume grows
An n8n instance installed with default settings processes executions one after another, on a single process. As long as you run a few hundred executions a day, nobody notices. The day a bulk job lands, the queue clogs and triggers pile up.
The vendor documents the way out, queue mode. Its page on scaling describes a main instance that receives triggers, a queue that holds pending executions, and workers you add according to load.
One last limit, and it surprises a lot of teams. Redundancy for the main instance stays reserved for the self-hosted Enterprise offer, and does not exist on the vendor's cloud. A company whose flows carry customer commitments must build that constraint into its recovery plan, alongside the governance described in AI agent security.
The first project I would not rebuild inside n8n
An internal document base queried by artificial intelligence, built node by node inside n8n. We did it. We would not do it that way again.
I explained why in my January 2026 post. Three traps come back every time. Document chunking, which flattens headings and tables. Syncing, because a knowledge base never stops moving. And permissions, because a colleague can end up reading a document they have no right to see.
As a learning exercise this build is excellent. For production, a dedicated product ships faster and handles permissions better. My review of Dust covers that French alternative. n8n then keeps a valuable role, it triggers, it monitors and it retries.
The second, the autonomous agent started too early
The other mistake happens before any tool is chosen. I detailed it in my newsletter on the topic. A company spots repetitive tasks and asks for an agent. In the vast majority of cases, a deterministic flow with one model call in the right place delivers the same service. For a fraction of the cost and the fragility.
n8n can do both, and that is exactly what makes the trap easy to fall into. The agent node drops in with two clicks. Supervision, guardrails and error recovery have to be built by hand.
If you are weighing an assistant, a simple automation, a flow with a model call and a full agent, the four levels of optimisation lays out the decision grid. And building an agent in n8n shows the build when an agent genuinely earns its place.
Does Claude Code replace n8n?
The question comes up in every workshop now that dev agents have landed inside companies. My answer is no, and the nuance deserves to be spelled out.
I wrote it up in my February 2026 post. A dev agent reproduces the logic of an n8n flow very quickly, data aggregation, business rules, API calls. The result is real, and it lands in two days rather than two weeks. The trap comes afterwards.
The two tools complement each other very well. The dev agent writes the hard business brick. n8n orchestrates it, watches it and retries it. That is how we work on most recent engagements.
The n8n licence, the point almost nobody reads
n8n is not open source in the classic sense. The licence file places the code under the Sustainable Use License. Its central clause lets you use or modify the software « only for your own internal business purposes or for non-commercial or personal use ».
In practice, a company automating its own processes has nothing to worry about. A vendor wanting to resell a product with n8n embedded must sign a commercial agreement. The line sits on what you bill a third party.
A second subtlety, the same file states that source files whose names contain « .ee. » fall outside that licence and require an Enterprise licence. The repository you self-host therefore contains code you cannot freely exploit.
Will n8n still be around in three years?
The question applies to any tool a company installs its processes on. It came up often two years ago. It comes up far less today.
SAP took a stake in the vendor in May 2026. The n8n announcement values the company at more than four billion euros, more than double the year before, and plans to embed n8n inside SAP's agent studio. The vendor also claims more than one and a half million active builders each month, and more than 1,400 enterprise customers.
For a smaller company building its automations on top, the survival of the tool stops being a topic. The signal still deserves to be read the other way round.
A vendor moving upmarket shifts its effort towards enterprise features. Releases follow each other faster, and breaking changes come with them. Our migration guide covers the most recent one. On our projects I now lock down two things from day one, a known version and a way to restore the flows.
The right question has little to do with the vendor surviving any more. It is about your own ability to keep up with its pace.
What we would do again, what we would avoid
| Need | Our pick | Why |
|---|---|---|
| Orchestrating and monitoring business flows | n8n | Visual logs, retries and alerts without writing code |
| Writing complex business logic | A dev agent, called from n8n | Fast to write, with supervision handed back to the platform |
| Querying an internal document base | A dedicated product | Chunking, syncing and permissions handled natively |
| Processing a large batch of documents | Self-hosted n8n, split into sub-workflows | The entry plan cuts off at 5 minutes per execution |
Should you choose n8n to automate your company?
Yes, in the large majority of cases, and that is a verdict more than 20 engagements have confirmed. No other tool gives this much control over business logic for such a modest subscription, while staying readable by someone who does not code.
The reservation is about the team. n8n needs someone who watches it, updates it and fixes it when an API moves. A company without that skill in-house must either hire it, outsource it, or stick to a handful of simple flows.
If you are still choosing your first projects, our AI audit exists for exactly that, mapping the tasks and sizing the impact before anything gets built. And if you are looking for a team to build and maintain your flows, that is what our n8n agency does. To see what a first end-to-end flow looks like, our n8n tutorial walks through it step by step.
