The first time an n8n workflow replaces a 300-line integration script, it feels like you got away with something. The second time that same workflow silently drops a webhook, retries a payment call twice, or fails because a third-party API changed its response shape, you realize the real question was never “Can we avoid writing code?”
n8n is not a way to escape engineering. It is a way to move engineering into a different shape. Sometimes that shape is better. Sometimes it makes the problem harder to test, harder to debug, and harder to evolve.
The decision to use n8n instead of writing custom code should not be based on whether you like visual editors. It should be based on the kind of work the automation does, the failure model you can tolerate, the people who will maintain it, and how central the behavior is to your product.
It may use expressions. It may use a Code node. It may rely on JSON transformations, conditional branching, HTTP requests, headers, authentication, retries, error paths, and data normalization. That is still logic. The difference is where the logic lives and how it is expressed.
When you write the code yourself, the logic lives in your application, your service, your tests, your deployment pipeline, and your observability stack.
When you use n8n, the logic lives in a workflow graph, execution history, credential store, node configuration, and possibly a mix of visual nodes plus custom JavaScript.
That distinction matters more than the surface-level “low-code versus code” debate.
n8n is strongest when it acts as a coordination layer between systems. It is weaker when it becomes the place where your core business rules quietly accumulate.
n8n is good at the kind of work that engineers often underestimate: integration glue.
That includes things like: Calling an external API when an event happens Syncing records between two systems Sending notifications to Slack, email, or messaging tools Reacting to webhooks Running scheduled jobs Polling an API when no webhook exists Transforming a payload from one shape into another Creating tickets, contacts, leads, or tasks in external systems Orchestrating a sequence of manual and automated steps Giving internal teams a visible place to inspect and rerun failed operations Automating operational processes that do not belong inside the main product codebase
This is real work. It is also the kind of work that becomes surprisingly expensive when written from scratch every time.
Then the actual requirements show up: The external API sometimes times out. The token expires. The payload has optional fields. The same event can arrive twice. The third-party sandbox behaves differently from production. The notification needs different formatting for different teams. The job needs to be manually rerun when a support case is fixed. Someone needs to see why it failed last Tuesday. The integration should not deploy with the main product every release. The ops team wants to tweak the message without opening a pull request.
At that point, writing the integration as a standalone service may still be correct, but it is no longer obviously correct.
Use n8n for operational automation around the product. Write code for behavior that is the product.
For example, n8n is usually a good fit for: Sending a Slack message when a high-value customer signs up Creating a CRM record when a form is submitted Syncing a support ticket system with an internal database Triggering a report export on a schedule Notifying a team when a deployment finishes Creating an onboarding task list when a user upgrades Calling an internal API to enrich a lead Posting an alert when a monitoring webhook fires Moving data between tools where eventual consistency is acceptable Running an internal process that a human may need to inspect or retry
It is usually a worse fit for: Billing calculation Authorization decisions Core financial transactions Fraud detection Real-time product APIs High-throughput event ingestion Complex domain state machines Strongly transactional operations Anything requiring fine-grained unit-test coverage of business rules Anything where a workflow execution log is not an acceptable audit trail
The difference is not technical impossibility. You can build complicated things in n8n. The difference is whether the tool’s failure modes and maintenance model match the importance of the task.
When you write an integration yourself, you usually need to build or reuse: HTTP client logic Authentication handling Token refresh Retry logic Timeouts Error classification Payload validation Idempotency handling Logging Metrics Alerting Background job execution Deployment configuration Secrets management Rate-limit handling Manual rerun support Admin visibility