Two tools, different strengths
n8n is a visual workflow automation platform. You connect nodes in a canvas, each node does one thing (fetch data, transform, send email, write to Sheet), and the workflow runs on a schedule or trigger.
Custom code is Python or TypeScript doing the same thing without the visual layer. More flexible, more powerful, harder for non-developers to understand or modify.
I use both. Sometimes in the same project. Here is how I decide.
When n8n wins
The logic is "if this, then that"
If a new lead arrives in HubSpot, enrich it, check if it matches the target criteria, and route it to the right sales rep. If a price drops below a threshold, send a Slack alert. If a new filing appears on SEC EDGAR, check the watchlist and trigger the parser.
This kind of conditional routing with multiple delivery targets is exactly what n8n is built for. The workflow is visual, the client can see the logic, and adding a new branch or delivery target takes minutes.
The client needs to modify it
When I hand off a project, some clients want to adjust the workflow themselves. Add a new Slack channel. Change the alert threshold. Add a CC to the email report. In n8n, these are drag-and-drop changes. In custom code, they require a developer.
If the client is non-technical and the workflow is likely to evolve, n8n reduces the ongoing dependency on me. That is good for the client and honest about what they need going forward.
The integration already exists
n8n has pre-built nodes for hundreds of services: Google Sheets, Slack, HubSpot, Airtable, Notion, Telegram, Discord, email providers, webhooks, databases. If every step in the workflow connects to a service that n8n already supports, writing custom code for the same thing is wasted effort.
The workflow is the product
For some clients, the automation is not a backend process. It is the thing they are selling or the thing their team interacts with daily. Being able to show the workflow visually in a client presentation or internal documentation has real value. n8n's canvas view is clear enough that a non-technical stakeholder can understand the flow.
When custom code wins
The extraction is complex
Scraping a website with anti-bot protection, JavaScript rendering, session management, and proxy rotation is not an n8n task. n8n's HTTP node can make API calls and simple requests, but anything that requires Playwright, browser fingerprinting, or adaptive rate limiting needs custom code.
In practice, most of my projects have a custom Python extraction layer feeding data into an n8n orchestration layer. The scraper does the hard work. n8n handles what happens after.
The transformation is heavy
Normalizing 42 fields across 932 county schemas is a Python job, not an n8n job. n8n has transformation nodes (Function, Code, Set), but complex data transformations with per-source mapping rules, dedup logic, and validation steps are easier to write, test, and debug in a proper codebase with version control.
Performance matters
n8n processes workflows sequentially and has memory limits per execution. Processing 50,000 records in a single workflow run can hit those limits. Custom code handles large datasets with streaming, batching, and parallel processing.
For pipelines that process thousands of records per run, the extraction and transformation run in Python. n8n triggers the script and handles the post-processing (delivery, alerting, logging).
The logic changes frequently
Counterintuitively, if the logic changes every week based on new requirements, custom code can be faster to iterate than n8n. Updating a Python script, running tests, and deploying takes minutes. Rebuilding a complex n8n workflow with 30 nodes because the branching logic changed is more work than editing a few lines of code.
The hybrid approach
Most of the automation I build for clients uses both. The split is consistent:
| Layer | Tool | Why |
|---|---|---|
| Data extraction | Python | Complexity, performance, anti-bot handling |
| Data transformation | Python | Schema normalization, validation, dedup |
| Orchestration | n8n | Scheduling, conditional routing, visual logic |
| Delivery | n8n | Google Sheets, Slack, email, CRM write-back |
| Monitoring | Both | n8n for alerts, Python for data quality checks |
The Python layer does the heavy lifting. n8n handles the "glue" between systems and the delivery to end users. The client sees and understands the n8n workflow. They never need to touch the Python code.
What it costs
An n8n workflow (standalone, no custom extraction) starts at $199 for setup. Typical use cases: CRM routing, notification automation, scheduled report delivery from an existing data source.
A hybrid pipeline (custom extraction + n8n orchestration + delivery) starts at $499/mo for the managed service. This includes the extraction, the n8n workflow, and ongoing maintenance of both.
n8n itself is open-source and self-hostable, or available as a cloud service at $20/mo for basic plans. For clients who want me to host the n8n instance as part of the managed service, that is included in the monthly fee.
The bottom line
n8n and custom code are not competitors. They solve different parts of the same problem. Use n8n when the value is in connecting systems and routing data. Use custom code when the value is in extracting or transforming the data itself. Use both when the project touches both.
The question is not "which one should I use?" The question is "where does the complexity in my workflow actually live?" If it is in the extraction, write code. If it is in the routing, use n8n. If it is in both, build both.