Writing7 min read
When no-code stops being the cheap option
There is a crossover point where a visual automation costs more than the code it replaced. Four signals that you have passed it.
- Build

I build on n8n and Make constantly, and I will keep doing it, because for a large class of problems they are genuinely the cheapest correct answer. But there is a crossover point where a visual automation starts costing more than the code it replaced, and most teams sail past it without noticing — because the cost arrives as friction rather than as an invoice.
Four signals that you have crossed it.
1. The canvas no longer fits on a screen
A workflow you cannot see all of is a workflow nobody can reason about. When a chain reaches forty-odd nodes with branches, the visual representation has stopped being an advantage and become an obstacle. Two hundred lines of readable code would fit on two screens, diff cleanly, and tell you what changed.
The tell: somebody asks "what happens if the email bounces?" and the honest answer is that you would have to trace it.
2. You are paying per operation for something trivial
Per-operation pricing is fine when each operation does real work. It is absurd when you are paying to move a field from one object to another eighty thousand times a month. At volume, a $12 container running a script beats a $400 platform bill, and the script does not rate-limit you during a launch.
Run the arithmetic before you scale, not after the first big month.
3. The logic has become genuinely conditional
Visual tools handle if this, then that beautifully. They handle if this, unless that, except when the account is on the legacy plan, in which case check the other thing first extremely badly. Every nested branch makes the canvas less legible, and eventually people stop changing it because nobody is confident about what else will move.
Business rules want to live in one function with tests, not spread across eleven boxes.
4. Nobody can debug it but the person who built it
This is the expensive one, and it is the one I care most about. If a workflow only makes sense to its author, you have not bought automation — you have bought a dependency. That is true whether the author is your operations lead or a studio like mine.
Code has an advantage here that people forget: it can be read, diffed, reviewed and searched. A canvas can only be squinted at.
What I actually do
Most of my builds are hybrid, and I think that is the right default. The triggers, the connectors and the boring plumbing stay in n8n, because that is genuinely faster and easier for a client to see and touch. The scoring, the parsing, the business rules and anything with real error handling get pulled out into a small service the automation calls.
You keep the visibility where visibility helps, and the logic where logic belongs.
The point is not that code is superior. It is that "no-code is cheaper" is a claim with an expiry date, and most teams never check whether theirs has passed.