n8n or Zapier or custom code: how to choose for an automation

Three ways to automate something. Zapier and its kin connect services you already use, with no infrastructure and no code. n8n does the same job but you can self-host it, and it will let you drop into code when the visual nodes run out. Writing it yourself gives you everything and costs you maintenance.

Where each stops being the right answer

Hosted no-code tools are excellent until one of three things happens: the per-run pricing outgrows the value at volume, the data cannot leave your infrastructure, or the workflow needs a step the platform simply does not have. Those limits arrive later than developers expect and sooner than non-technical buyers hope.

n8n sits in the middle honestly. Self-hosting removes the per-run cost and keeps data in-house, and the code node means an awkward step does not end the project. The price is that you now run a service: updates, backups, an eye on it.

What self-hosting actually asks of you

Self-hosted is not free, it is differently priced. You are running a service that needs somewhere to live, updates applied, backups of its credentials and workflow definitions, and someone who notices when it stops. For a team that already runs infrastructure that is close to nothing; for a team that does not, it is a new responsibility that tends to be discovered the first time a workflow silently stops firing.

A worked example

Say enquiries need to reach a CRM, a Slack channel and a spreadsheet. Every one of those connectors exists in every tool on this list, so buy it — the value is in the plumbing being someone else’s problem. Now add: score the enquiry against how the team actually qualifies work, and route the ambiguous ones to a human with the reasons attached. Nothing off the shelf does that particular judgement, and it is the part that saves real time. Bought plumbing, built judgement.

The rule I use

Buy the commodity, build the workflow. Where the task is generic and a good product exists — transcription, scheduling, notifications, accounting exports — use it and move on. Build where the job is specific to how your team actually works, because that is exactly where off-the-shelf automation leaves the awkward parts with the humans, which was the whole problem.

• —A handful of runs a day, standard services, no sensitive data: hosted, no-code. Ship it this afternoon.
• —High volume, or data that must stay in-house: self-hosted n8n, if someone will own the box.
• —The valuable part is judgement specific to your business: write it, and keep the generic steps bought.
• —Whatever you choose, design it to flag ambiguity rather than guess — an automation that is confidently wrong is worse than none.

Knowing when not to automate

Some tasks look automatable and are not worth it: they run twice a month, the rules change constantly, or the failure is expensive enough that a human would have to check the output anyway — at which point you have added a system and kept the labour. The test is not "could this be automated" but "would I trust it unattended after a month of watching it". If the answer is no, the honest move is to leave it alone and automate something else.

Buy the commodity, build the workflow.