Most businesses land on Zapier or Make because they're easy to find, easy to start, and the pricing looks reasonable. Then six months later, someone's manually handling every exception the workflow can't deal with — which turns out to be quite a lot of them.

I've built automations in all three environments. The honest answer to which one you should use isn't about the tools. It's about what your operations actually look like. Here's how to figure that out.

What each approach actually does (and what it can't)

Before comparing, worth being clear on what you're actually choosing between. These are not interchangeable tools with different price tags. They handle fundamentally different levels of complexity.

Zapier — fast setup, limited ceiling

Zapier is a trigger-action tool. Something happens in one app, something happens in another. It's good at simple, linear workflows: a form submission creates a CRM record and sends a Slack notification. Setup takes minutes, it's reliable for exactly what it's designed to do, and the app library is enormous.

The ceiling is low though. Conditional logic is basic. There's no real reasoning layer. If your process has exceptions — and most real business processes do — you end up bolting on manual steps to handle them. At that point you haven't automated the work, you've just moved it around.

Zapier works well for: small teams, simple linear workflows, businesses that haven't hit process complexity yet.

Make.com — more power, still template-bound

Make gives you more flexibility. Visual flow builder, better branching logic, data transformation, the ability to handle more complex multi-step workflows. It's the natural next step for businesses that've outgrown Zapier's basics.

But it's still fundamentally template-bound. You're connecting apps that have pre-built integrations, working within the data structures those integrations expose, and building logic that has to be explicit and rule-based. If the data coming in is messy, inconsistent, or needs judgement to interpret, Make doesn't have an answer for that. You end up writing workarounds that become fragile over time.

Make works well for: mid-complexity workflows, businesses with structured data and predictable inputs, teams with some technical capacity to maintain it.

Custom AI builds — when the rules don't fit your process

A custom build, built with Claude Code in our case, isn't a third automation platform. It's a purpose-built system that handles your specific operations, including the parts that don't follow a predictable pattern.

The key difference is the reasoning layer. When a supplier sends a PDF in a format you've never seen before, a custom AI system can read it, extract what it needs, and handle it. When a customer request has three possible interpretations depending on context, a custom system can apply the right logic. Zapier and Make need the input to be structured and predictable. Custom builds can handle the messy reality of how business data actually arrives.

Custom builds work well for: operationally complex businesses, high-volume workflows where licensing costs mount, and processes where exceptions are the rule rather than the exception.

The decision matrix: which businesses suit which tool

The question isn't which tool is best in the abstract. It's which one fits what you're actually trying to automate.

Operational complexity as the deciding factor

The clearest signal is how often your processes have exceptions. If you can document your workflow as a clean flowchart with predictable yes/no branches, Zapier or Make will probably handle it. If a human currently makes judgement calls at multiple points in the process, a no-code tool will miss those calls or push them back to a human.

A removals company we worked with had a quoting process that involved reading supplier availability data from emails, cross-referencing job requirements, and applying pricing logic based on about a dozen variables. Make can't reason across unstructured email content. Zapier can't apply conditional logic that complex. A custom AI system handles it in seconds, every time.

Here's a rough comparison table to orient your thinking:

Volume and cost thresholds that change the math

Zapier and Make both charge by task or operation volume. At low volume that's fine. At scale, it adds up fast.

A business running 50,000 automated tasks per month on Zapier's Professional plan can easily be spending £400–800 per month, just in licensing. A custom build has a one-off development cost and then runs on minimal infrastructure, typically £20–50/month. The crossover point is usually somewhere in the 20,000–40,000 tasks per month range, depending on complexity.

Beyond raw task volume, think about what happens when the business changes. On Zapier or Make, every workflow change means someone reconfiguring templates. On a custom build, changes are handled in code, properly versioned, and don't break adjacent workflows when you update one part.

Where Zapier and Make break down in practice

I want to be specific here, because most content on this topic is vague about where no-code tools actually fail. These are the patterns we see repeatedly.

Edge cases, supplier data, and reasoning gaps

The most common failure mode: the workflow runs fine for 80% of cases and silently breaks or creates wrong outputs for the other 20%. Because Zapier and Make don't reason, they can't flag uncertainty. They either complete the action or throw an error.

Supplier data is particularly problematic. Suppliers send PDFs, non-standard CSV formats, emails with important data buried in free text. No-code tools need clean, structured inputs. When the input isn't clean, the workflow either fails or, worse, processes it incorrectly without anyone noticing.

We built a system for a logistics client that was previously trying to handle supplier confirmations via Make. The issue was that different suppliers used different terminology, different date formats, and occasionally sent partial information that needed follow-up. Make had no way to interpret ambiguity. The custom build read the email content, understood what was and wasn't confirmed, and either completed the workflow or flagged it for human review with the relevant context highlighted. That's a reasoning problem. No-code tools don't solve it.

What happens when your workflow has exceptions

Every real business process has exceptions. A customer submits a form with unusual requirements. A supplier changes their pricing structure without warning. An order comes in for a combination of products that doesn't fit the standard fulfilment path.

With Zapier or Make, exceptions typically fall out of the workflow entirely and land in someone's inbox as a manual task. The automation handles the easy cases; someone still has to handle the hard ones. That's better than nothing, but it's not really automation. It's partial automation that still requires operational overhead.

With a custom build, you can programme how exceptions are handled: route them to a specific person, request additional information automatically, apply a fallback logic path, or escalate based on the nature of the exception. The system does more of the thinking.

Real cost comparison: licensing vs custom build over 12 months

Let me walk through a concrete example. A professional services firm with 25 staff, running a client intake process, proposal generation workflow, and monthly reporting, roughly 30,000 tasks per month across these processes.

Zapier (Professional plan, scaled): approximately £500–700/month. Over 12 months: £6,000–8,400 in licensing alone. Any workflow changes require someone's time. Complex exceptions still handled manually.

Make.com (Teams plan, scaled): approximately £250–400/month. Over 12 months: £3,000–4,800. Better value, but same ceiling problems. The intake process has too many conditional branches for Make to handle reliably.

Custom AI build (AMPL): audit and scoping first (refundable against build), development typically £8,000–15,000 depending on complexity, infrastructure running costs £30–60/month. Month 1–3: higher upfront. Month 4 onwards: licensing cost drops to near zero. By month 12 you're ahead on cost, and the system is doing things Zapier and Make couldn't do at any price.

To be honest, the cost comparison isn't the main reason most businesses choose a custom build. The main reason is that the custom build actually solves the problem, and the no-code tools don't, regardless of cost.

FAQ

Can I start with Zapier and migrate to custom later?

Yes, and for a lot of businesses that's the right approach. Zapier or Make to handle the basics while you validate the workflow and understand where the real complexity sits. Then migrate to custom for the processes that justify it. One thing to flag: make sure you're documenting the edge cases as you go. That context is valuable when you do build the custom system.

Is Make.com better than Zapier for complex workflows?

Make handles more complexity than Zapier. Better branching logic, more powerful data transformation, more flexibility in how you structure flows. For a lot of businesses in that middle tier, Make is the right tool. But both tools hit their ceiling when the workflow needs genuine reasoning: interpreting unstructured data, handling ambiguous inputs, or applying logic that can't be expressed as explicit rules. That's where custom builds take over.

When does a custom AI build make financial sense?

A few signals: your task volume puts you above £300/month on no-code licensing; your process has significant exception handling that currently requires manual input; your workflow involves unstructured data like emails, PDFs, or supplier communications; or you've already tried to automate something with Zapier or Make and it didn't stick. If two or more of those are true, the custom build conversation is worth having. The audit will tell you whether the numbers work.

What's the main reason no-code automations fail?

Exceptions. Every no-code tool assumes clean, predictable inputs and linear process flows. Most real business processes have neither. The tool handles the standard cases fine; the exceptions pile up as manual tasks; someone eventually switches the automation off because it's causing more problems than it solves. Custom builds handle exceptions as part of the design, which is why they tend to stick.

Do I need technical staff to maintain a custom AI build?

Not necessarily, though it depends on how the build is handed over. We include documentation and basic configuration access in every build so operational staff can make minor changes without code. For anything more significant, we're on retainer. The maintenance overhead is much lower than people expect. The system runs itself, and updates are typically triggered by business changes rather than tool changes.

Is it possible to build on both — use Zapier for simple things and custom for complex?

Completely. Most of our clients run a mix. Zapier handles Slack notifications, simple CRM updates, calendar bookings. The custom system handles the complex stuff: the intake process, the supplier data pipeline, the reporting layer. You don't have to replace everything. Just replace the things that are genuinely breaking.

If you're not sure which category your current automations fall into, that's exactly what an audit is for. We map your processes, identify where no-code is working fine and where it's costing you more than you think, and give you a clear picture before you spend anything on a build.

If this sounds like the situation you're in, we should talk. Book a free audit at amplconsulting.ai.