n8n vs a custom script: when each one is the right call

I get asked this almost every week now. Someone read that n8n can automate anything, or someone else got burned by a workflow tool that fell over the second the logic got weird. Both reactions are right, depending on the job. Here is how I actually decide, based on projects we have shipped at Esipick.

What n8n is actually good at

n8n wins when the job is mostly connecting things that already exist. Pull a row from a spreadsheet, check a condition, send a Slack message, update a CRM field, trigger an email. If you can draw the flow on a napkin in five boxes, n8n is the right call. You get a visual log of every run, you can pause and rerun a single failed step, and anyone on the team can open it and understand what happened without reading code.

It is also the right call when the client or their team needs to maintain it themselves eventually. A script lives in a repo only the original developer understands. A workflow lives in an interface a marketing ops person can poke at six months later.

When a custom script is the better tool

The moment the logic stops being "if this then that" and becomes actual computation, I reach for a script instead. Things like scoring leads against a weighted formula, parsing a messy PDF layout, deduplicating records against fuzzy name matches, or doing anything that needs a loop with real state. n8n can technically do these with its code node, but at that point you are writing JavaScript inside a tool built for drag and drop nodes, and you lose version control, proper testing, and the ability to reason about the whole thing at once.

Speed and cost matter too. A script that runs in a lightweight container on a schedule is cheaper and faster than a workflow tool spinning up for the same job, especially at volume. If you are processing thousands of records a day, that difference adds up.

The real test I use

I ask one question: does this need to be readable by a non developer, or does it need to be fast and precise? Readable and collaborative, go n8n. Fast, precise, and heavy on logic, go custom script. Most projects are actually a mix, and that mix is fine. We regularly build a script that does the hard computational work and have n8n sit on top of it handling the triggers, notifications, and human in the loop steps.

• Choose n8n for: connecting SaaS tools, simple conditional logic, workflows a client team needs to see and edit
• Choose a script for: heavy data processing, custom scoring or matching logic, anything running at high volume or needing strict cost control
• Combine both when: you need computational depth plus a visible, editable workflow layer on top

What running Esipick taught me here

We used to try to force everything into n8n because it felt like the "modern" way to build automations fast. Then we built a client project that scored incoming applications against a dozen weighted criteria, and the workflow turned into an unreadable maze of code nodes. We ripped the scoring logic out into a plain script, kept n8n for the intake and notification steps, and the whole thing got easier to maintain and noticeably faster. Now that split is basically our default architecture for anything with real logic in it.

Neither tool is the hammer for every nail, and the fastest way to waste a client's budget is picking one because it is trendy instead of because it fits the actual shape of the problem.