n8n, Make or custom code: choosing your automation stack
The wrong question is "which tool is best". The right one is "what will it cost to operate this a year from now". A practical criterion, with the trade-offs we see in real projects.
Almost every week we hear the same question: “should we use n8n, Make, Zapier, or hire someone to code this?” The question hides a common mistake: choosing the tool before understanding the problem — and before thinking about who will keep the thing running a year from now.
We run all three approaches in production. Here’s how we decide, and why.
The criterion: total cost of operation
An automation isn’t a project — it’s a system that stays running. The real cost includes building, licences, and above all maintenance: who understands the workflow, who changes it when the process changes, who wakes up when it breaks at 3 a.m. The right tool minimises that total, not the build time.
When we choose Make or Zapier
Simple, linear flows between well-known tools. Form → CRM → welcome email. Invoice received → Drive folder → Slack notification.
- For: up and running in hours; hundreds of ready-made integrations; the team can see and adjust it without a developer.
- Against: pricing grows with operation volume; complex logic becomes module spaghetti; limited debugging.
Rule of thumb: if the flow has fewer than ten steps and no complicated branching, Make/Zapier is probably the cheapest answer — even with the subscription.
When we choose n8n
Our favourite sweet spot for SMEs. n8n is open-source, can run on your own server or their cloud, and handles serious logic: branching, loops, error handling, embedded JavaScript when needed.
- For: predictable cost (self-hosted pays nothing per operation); visual workflows the team can read; native AI nodes for calling Claude, GPT and friends; no lock-in.
- Against: needs someone to administer it (updates, backups); steeper learning curve than Make.
Rule of thumb: medium-to-high volume, branching logic, sensitive data that shouldn’t pass through third parties, or a budget that can’t take per-operation pricing — n8n.
When we choose custom code
When the automation is the product, or when failure is expensive. Integrations with systems that have no connectors, high volume with latency requirements, complex business logic, or flows that need proper automated testing and versioning.
- For: full control; testable, versionable, auditable; unbeatable marginal performance and cost at scale.
- Against: more expensive to build; needs a developer for any change.
Rule of thumb: if the flow is business-critical, changes rarely but must not fail, or is part of a product — code, with CI and monitoring.
The answer we give in practice
Most of our clients end up with a combination: n8n as the backbone of internal automation, code for the critical or high-volume pieces, and occasionally Make for peripheral flows the team wants to manage on its own.
What we never recommend: picking the tool first and hunting for problems for it afterwards. Describe the process, the volume, the cost of a failure and who will maintain the system — and the stack almost chooses itself.