n8n or custom development: where the line runs
n8n covers more than people assume, and we regularly recommend starting there. But a workflow builder has a boundary, and it runs not through scenario complexity but through the cost of a mistake, concurrency and access rights. How to work it out in advance and when writing code becomes the cheaper option.
10 min read
Honestly, first: what n8n does well
We recommend a builder more often than development, and that is not modesty. If the task sounds like “when an invoice email arrives, drop the file in a folder, create a CRM record and post to chat”, n8n solves it in an evening. Development loses on every count here: more expensive, slower, and nobody to maintain it.
Self-hosting is a separate strength. n8n ships under the Sustainable Use License: running it in-house for internal purposes is free and the data stays inside your perimeter. For a company that cannot let documents leave the building, that matters.
How the bill works: you pay per run, not per step
This is the first thing that breaks people's estimates. In n8n cloud the billing unit is an execution — one run of the whole workflow, no matter how many steps it contains. On the pricing page (checked 6 September 2026) Starter is €20/month billed annually with 2,500 executions, Pro is €50 with 10,000, Business is €667 with 40,000.
Count events, not steps. A hundred emails a day is three thousand executions a month, so Starter is already too small. Meanwhile a forty-node workflow that runs once a day costs thirty executions a month. Scenario complexity does not affect the bill at all.
Five signs the builder is running out
The boundary is not where the scenario got long. It is where at least one of these appears.
- Concurrency. In n8n the number of simultaneous executions is fixed by plan: 5 on Starter, 20 on Pro, 30 on Business. Going over does not error — runs queue up. If you get a burst of a thousand events in a minute and the answer is needed immediately, the queue becomes a business-side outage.
- Idempotency. A scenario retried after a timeout and the request was filed twice, the money debited twice, the customer emailed twice. In a builder you assemble retry protection by hand from checks and an external state store, and with every such patch the “built it in an evening” advantage melts away.
- Access rights. A scenario runs under one technical account and sees everything that account sees. The moment automation starts showing data to employees you need rights scoped to the individual user — otherwise what you built is not automation but a leak.
- Testability. You cannot run a workflow against forty scenarios before rollout and get a report. While changes are rare that is tolerable. When the process feeds revenue and changes weekly, the absence of tests becomes the main risk.
- Ownership. A scenario is usually assembled by one person and lives exactly until their holiday. Code with change history, review and documentation survives staff turnover; a node diagram that exists in one head does not.
What the free self-hosted edition does not have
“We will host it ourselves for free” is true but incomplete. Per the official edition comparison, the Community edition does not include SSO (SAML and LDAP), projects, Git-based versioning, environments, external secrets, log streaming, or sharing of workflows and credentials: access belongs to the instance owner and the creator.
For one engineer automating their own work none of that matters. For a ten-person department that needs separate access, a staging environment and a secrets store, that list is precisely why people move to a paid edition or to code.
The hybrid we recommend most often
The choice is rarely binary. The pattern that works looks like this: n8n stays the orchestrator — it receives events and talks to mail, calendar, CRM and messengers — while everything with a cost of failure moves into one or two of your own services behind a clear API.
What moves into your own service: charges and any irreversible operation, permission checks scoped to a user, personal data handling, model calls with cost control, and anything that needs test coverage. n8n keeps doing what it is good at: wiring services together and letting a non-technical person see what is happening.
How to cost it over two years, not the first month
Comparing “€20 a month against a development budget” is meaningless: they are different lines. Count four: subscription or hosting, human time spent maintaining scenarios, the cost of an incident times its probability, and the cost of migration if the platform stops fitting.
The fourth line is the forgotten one. Logic assembled from nodes does not port: you cannot export it to code, you rewrite it from screenshots. The longer you live on a platform the more expensive leaving becomes — and the more it matters to decide up front which part of the system is allowed to live there.
When development is not needed
We prefer to say this plainly, because an honest answer saves more than a clever architecture. Stay on the builder if the process runs rarely, a mistake is reversible and cheap, the integrations exist off the shelf, the data is not personal, and no money moves inside the scenario.
All five true — development will not pay off, and offering it would be dishonest. Two or more false — do the four-line calculation above: by the end of year two the numbers usually stop favouring the platform.