Zapier, n8n, or Custom: How to Actually Choose

We build custom automation for a living, so treat the following with appropriate suspicion: most automation should not be custom.

If your problem is “when a form is submitted, create a row and notify a channel,” a no-code tool will solve it this afternoon for a few dollars a month, and anyone suggesting a bespoke build is selling you something. That covers a genuinely large share of real automation needs.

The interesting question is where that stops being true. In our experience it is five specific situations, and none of them are about scale alone.

1. The input is unstructured and judgement is required

No-code platforms are exceptional at moving structured data between systems. Field A goes to field B. Conditional logic on known values. Clean, reliable, well-supported.

They struggle the moment the input is a document, an email thread, a scanned form, or a free-text description that requires interpretation. Yes, most now offer an AI step. That step is a single model call with a prompt box, which is enough for classification and simple extraction, and nowhere near enough when you need retries, schema validation, confidence thresholds, fallback strategies, or an evaluation harness that tells you whether last week’s prompt tweak made things worse.

If the core of your process is “read this and work out what it means,” you have crossed the line.

2. The branching has outgrown what stays readable

Every visual workflow builder has a complexity ceiling. Not a technical one — a human one. Somewhere around fifteen or twenty branching nodes, the canvas stops being a diagram that explains the process and becomes a diagram that requires the process to be explained first.

Code has the opposite property. It handles branching complexity well, it diffs, it reviews, it tests, and it carries comments explaining why a strange condition exists.

3. The per-task pricing has inverted

No-code pricing is per operation, and it is genuinely cheap at low volume. At high volume the arithmetic turns.

Run the numbers honestly, and remember that one logical “task” is often five or ten billable operations once you count the branches, lookups, and error paths. We have seen teams paying four figures a month for a workflow that runs as a scheduled function for the cost of a cup of coffee.

The threshold moves with the platform and your plan, so the real advice is: actually calculate it. Multiply your realistic monthly volume by the operations per run and compare against a few weeks of build time amortised over two years. Sometimes no-code still wins. Often it does not, and nobody had checked.

4. Failure needs to be handled, not just retried

No-code error handling is typically a retry and an alert. That is adequate when a failure means “try again in five minutes.”

It is not adequate when:

• The operation is not idempotent and a retry causes a duplicate charge, message, or record.
• A partial failure leaves two systems inconsistent and something has to reconcile them.
• Work needs to survive a multi-hour outage in a downstream service rather than being dropped.
• A failed item needs to go somewhere a human will actually see it, with enough context to act.

Durable execution — where a workflow can pause for hours, resume exactly where it stopped, and guarantee each step runs once — is a property you either have or do not. If your process needs it, that decides the question.

5. It is becoming a product, not a workflow

Automations have a habit of accreting. It starts as a scheduled job, then someone wants a view of what it did, then a way to override a decision, then a second team wants their own configuration, then a client asks for a report.

At that point you do not have an automation. You have an application that has not admitted it yet, running on infrastructure with no version control, no test suite, no staging environment, and no way to review a change before it hits production.

The migration is much less painful if you notice early. Recognising when a workflow has become a product is worth doing deliberately rather than discovering it during an incident.

The honest comparison

| | No-code | Custom | |---|---|---| | Time to first version | Hours | Weeks | | Cost at low volume | Very low | High | | Cost at high volume | High | Very low | | Unstructured input | Weak | Strong | | Complex branching | Degrades fast | Scales well | | Error handling | Retry and alert | Whatever you need | | Version control | Limited or none | Native | | Who can maintain it | Anyone technical-ish | Someone who codes | | Vendor risk | Real | None |

That last row cuts both ways. No-code means a pricing change or a deprecated integration is somebody else’s decision affecting your operations. Custom means you own the maintenance. Neither is free.

The pragmatic middle

The best architecture we see is frequently a hybrid, and it is under-used.

Keep the no-code platform as the trigger and routing layer — it is genuinely good at that, and it lets non-engineers see and modify the top-level flow. Call out to a custom endpoint for the step that needs real logic. The AI reasoning, the complex validation, the transactional database work happens in code with proper testing; the orchestration stays visible and editable by the team.

This gets you the visibility of no-code and the correctness of custom, and it means the eventual migration path is a matter of moving one step at a time rather than a rewrite.

How to decide this week

Take your most annoying process and answer four questions:

1. Does any step require interpreting unstructured input? If yes, lean custom.
2. Could a new colleague understand the flow unaided? If no, lean custom.
3. What does it cost per month at realistic volume? Compare properly against build cost.
4. What happens if a step fails at 3am? If the answer needs to be better than “it retries and someone gets an email,” lean custom.

Three or four yeses and the build is probably justified. One or none, and you should open Zapier and be done by lunchtime.

We build the custom side, and we will tell you when you do not need us. See how we approach automation.