| What you are deciding on | No-code (n8n, Make, Zapier) | Custom development |
|---|---|---|
| Time to first working version | Days. This is the genuine advantage and it is a large one. | Weeks. Justified only when the flow needs something the platform cannot express. |
| Build cost | Lower, often much lower, for flows that fit the model. | Higher up front, flatter afterwards. |
| Running cost | Per-operation pricing. Cheap at low volume; it scales linearly and can overtake a build at high volume. | Infrastructure only. Effectively flat as volume grows. |
| Complex branching | Possible and quickly unpleasant. A canvas with forty nodes and nested conditions is harder to read than the code it replaced. | What code is for. Conditions, retries and edge cases stay legible. |
| Testing | Largely manual. Little or no unit testing, and regression testing means clicking through it again. | Automated tests, staging environments, a real deployment pipeline. |
| Version control and review | Workflow JSON can be exported and committed, but diffs are barely reviewable in practice. | Ordinary code review, history and rollback. |
| Who can change it | A capable analyst. This matters more than it sounds — it removes a queue. | A developer. Slower, but nobody changes production by dragging a node. |
| Failure behaviour | Depends on the platform and on how carefully error paths were configured. Silent partial failure is the common one. | Explicit: retries, dead-letter handling, alerting, whatever the process needs. |
| Lock-in | Real. The logic lives in the platform’s format, and migrating means rebuilding. | Low. The logic is code you own and can move. |
We build on both, and roughly half of our delivered flows have a no-code platform somewhere in them. There is no purity argument here, only a fit argument.
The volume is high enough that per-operation pricing becomes the largest line in the running cost.
The logic branches heavily, or the same flow has to behave differently for a dozen cases.
A silent failure would be expensive — payments, clinical or legal outputs, anything customer-facing at scale.
You need audit trails, four-eyes approval or data residency guarantees the platform does not give you.
The flow is linear, the volume is modest and connectors already exist for both systems. Build it on the platform this week.
You are still validating whether the process is worth automating at all. A no-code prototype is the cheapest possible answer.
The people who own the process want to change it themselves without waiting for a developer.
It is internal, low-stakes, and an occasional failure costs an apology rather than money.
The most economical pattern we see is not choosing once. Build version one on n8n or Make, because that answers the only question that matters early — does this process actually work when automated, and what do the exceptions really look like. Run it for a month.
Then look at what the month produced. Most flows should stay exactly where they are; they work, they are cheap, and rewriting them would be an aesthetic decision. The ones that move to code announce themselves: the operation bill is climbing, the canvas has become unreadable, or a silent failure has already cost something.
A hybrid is also normal and often the best answer. The platform handles orchestration, triggers and the connectors it does well; a service you own handles the part with the difficult logic. You keep the speed of the canvas where it helps and the rigour of code where it is needed, and neither is doing a job it is bad at.