Most teams should start with no-code. The interesting question is knowing when you have outgrown it — and this guide is mostly about recognising that line rather than arguing for either side.
If a no-code tool can do the job, use it. It will be running this afternoon, someone non-technical can maintain it, and you will not be paying anyone to keep it alive. Reaching for custom code first is the more common and more expensive mistake.
The reason to move is almost never "no-code is not powerful enough" in the abstract. It is specific: the logic branched past readability, the volume made per-task pricing hurt, the data could not leave your environment, or the job needed real reasoning over messy input rather than field mapping.
Generalisations — check current pricing and features before deciding.
| Zapier | Make | n8n | Custom AI agent | |
|---|---|---|---|---|
| Best at | Breadth of integrations and getting something live fastest. | Visual multi-step logic with branching and iteration. | Self-hosting and complex flows without per-task pricing. | Reasoning over messy input and non-deterministic decisions. |
| Who maintains it | Anyone on the team. | Someone comfortable with a visual builder. | Someone technical, especially if self-hosted. | An engineer, or a team trained at handover. |
| Cost shape | Per task; rises sharply with volume. | Per operation; usually cheaper at volume than Zapier. | Free to self-host, plus your infrastructure and time. | Build cost up front, then model and hosting costs. |
| Data control | Runs in their cloud. | Runs in their cloud. | Self-host for full control. | Runs wherever you choose. |
| Handles unstructured input | Basic, via AI steps. | Basic, via AI modules. | Good, with custom nodes and code. | This is the actual reason to choose it. |
| Multi-step reasoning | Limited. | Limited to branches you define. | Possible with effort. | Native — plan, act, observe, retry. |
One of these alone is rarely enough. Two or three usually is.
Nobody can say with confidence what the scenario does any more, and changing it safely requires the person who built it.
Volume grew to where the monthly bill is comparable to building and hosting something purpose-built.
The job is reading an email, document, or transcript and deciding what it means — not mapping field A to field B.
The work needs a loop that evaluates its own output and adapts, not a fixed sequence of steps.
Compliance or contracts require processing inside your own environment.
You want evals, regression tests, and observability on decisions — which no-code tools do not really provide.
You rarely have to choose globally. The common ending is a no-code tool still handling triggers, connectors, and notifications, with the one genuinely hard step calling out to a custom agent over an API.
That keeps the parts your team can maintain in a tool they already understand, and isolates the part that needed engineering. It is also the cheapest migration path, because nothing has to be rebuilt at once.
Describe the process in plain language, including what a person does when the input is weird. That sentence usually reveals whether it is mapping or judgement.
Build it in whichever tool you already pay for. If it works, stop. You have your answer and it cost an afternoon.
Note the specific step that is fragile, expensive, or impossible — that step, not the whole workflow, is the candidate for custom work.
Keep the surrounding automation and call out to a custom agent for the hard part. Re-evaluate once it has run for a few weeks.
Sometimes the useful work is choosing correctly and setting up the no-code version properly, not building anything custom. I help teams decide which side of this line they are on, implement the no-code version when that is the right answer, and build the custom step when it genuinely is not. If the honest answer is that you do not need me, that is the answer you will get.
Both have AI steps that are fine for single calls — classify this, summarise that. Neither is really built for multi-step agent loops that plan, call tools, check results, and retry. For that you will be fighting the tool rather than using it.
Often yes. It is self-hostable, avoids per-task pricing, and lets you drop into code for the hard bits, so it covers a lot of ground between no-code and fully custom. The trade-off is that someone has to run and maintain it.
When the job requires reading unstructured input and making a judgement, when it needs a loop with self-checking, when data cannot leave your environment, or when volume makes per-task pricing worse than building. Best signal: several of those at once.
Yes, and it is usually the right sequence. Building it in no-code first forces you to write down the process precisely, which is most of the specification work for a custom version anyway.
No. Replacing the single step that strains, while leaving triggers and connectors in the no-code tool, is cheaper, lower-risk, and keeps the parts your team can maintain.
Running cost is model usage plus hosting, which for most internal workflows is modest next to per-task automation pricing at volume. Build cost is the larger number and depends entirely on scope, so it is worth pricing both paths against your actual volume before deciding rather than assuming custom is expensive.
Describe the workflow and the tool you are using now. I will tell you whether it is a no-code problem or genuinely needs a custom agent.
Get in touch →Got an idea, question, or just want to say hi?