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 custom 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 comes down to 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 needs interpretation. Yes, most now offer an AI step. That step is a single model call behind 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’ve 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 can carry a comment explaining why a strange condition exists.

3. The per-task pricing has inverted

No-code pricing runs per operation, and it’s 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’ve seen teams paying four figures a month for a workflow that would run 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 to actually calculate it. Multiply your realistic monthly volume by the operations per run and compare that against a few weeks of build time amortised over two years. Sometimes no-code still wins. Often it doesn’t, and nobody had checked.

4. Failure needs to be handled, not just retried

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

It stops being fine when the operation isn’t idempotent and a retry causes a duplicate charge, message, or record. Or when a partial failure leaves two systems inconsistent and something has to reconcile them by hand. Or when the work needs to survive a multi-hour outage in a downstream service instead of just getting dropped. Or when a failed item needs to land somewhere a human will actually see it, with enough context to act on.

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 don’t. If your process needs it, that alone settles 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 its own configuration, then a client asks for a report.

At that point you don’t have an automation anymore. You have an application that hasn’t 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 on purpose, rather than discovering it during an incident. An outreach sequencer is a common early example: once it needs to track each lead’s position across steps, enforce send limits, and handle replies correctly, it is a state machine, and the architecture that follows is code, not a Zap.

The honest comparison

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 yourself. Neither is free.

The pragmatic middle

The best architecture we see is often a hybrid, and it’s under-used.

Keep the no-code platform as the trigger and routing layer. It’s 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, while the orchestration stays visible and editable by the team.

That 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. Does any step require interpreting unstructured input? If yes, lean custom. Could a new colleague understand the flow unaided? If no, lean custom. What does it cost per month at realistic volume, compared honestly against the build cost? And what happens if a step fails at three in the morning? 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.