When Zapier is enough (and when it isn't)

We build the expensive tier of automation — MCP servers, agents with judgment in the loop, approval gates — so take this as a guide from people with every incentive to tell you Zapier is beneath you. It isn’t. For a specific class of workflow, Zapier or Make is the correct engineering decision, and paying us to replace it would be malpractice. The trick is knowing where the class ends, because the failure on either side is expensive: heavy machinery for a trivial mapping, or a pile of zaps doing load-bearing work nobody understands.

Where Zapier is exactly right

Four conditions, all of which need to hold:

• The trigger is clean. “New row in this form,” “new subscriber on this list” — a well-defined event from a system with a solid integration, not something inferred from three signals.
• The mapping is deterministic. Field A goes to field B, always. No reading the message to decide what kind of message it is, no policy, no exceptions list living in someone’s head.
• Volume is modest. Dozens or hundreds of tasks a month, where per-task pricing is noise.
• Failure is visible and cheap. If the zap silently stops, someone notices within a day because an expected Slack message doesn’t arrive, and the cost of a missed run is an apology, not a compliance question.

Form-to-CRM, demo-booking-to-Slack, invoice-paid-to-spreadsheet: correct Zapier, forever, live in twenty minutes. Anything we could build there would be strictly worse per dollar.

The signs it has stopped being enough

Each of these is a hard boundary, not a matter of taste:

• The workflow needs judgment. Reading a support email to decide whether it’s a refund request, a bug, or churn risk; applying a policy that has exceptions. Zapier’s filters can match keywords; they cannot read context, and keyword rules aimed at judgment problems fail quietly and constantly.
• State across steps. “If they haven’t replied in five days, and their plan is annual, and we already sent one reminder” — Zapier holds state in Delay steps and lookup-table duct tape, and the duct tape becomes the system.
• Branching that becomes topology. One zap with a filter is fine. Fifteen zaps triggering each other through helper spreadsheet rows is a distributed system with no source control.
• Per-task cost at volume. Multi-step zaps at thousands of runs a month climb to $300–600, more than the compute for a script doing the same job costs in a year.
• Auditability. When “what exactly happened to this record and why” is a question a customer, auditor, or regulator can ask, task history in a SaaS UI is not an audit trail.

The failure pattern has a shape we’ve seen enough to name: zap sprawl. One company — and it’s every company at about 40 people — had 23 zaps built by three different operators over two years. All three had left. The zaps triggered each other through shared sheets; some fired twice; two contradicted each other on lead routing. Nobody could turn anything off, because nobody could say what would stop happening. That isn’t an automation stack; it’s an outage that hasn’t picked a date yet.

The middle tier everyone skips

Between “zap” and “agent” sits a tier that gets skipped in both directions: a 50-line script on a scheduler. A cron job, a GitHub Action, a small worker that pulls from an API, applies your actual logic in real code, and writes the result — with version control, code review, a log line per decision, and a test. It handles state, real branching, and volume at effectively zero marginal cost, and it beats a $600-a-month zap tangle and a premature agent alike. Most of what companies call their “automation roadmap” is honestly this tier: deterministic logic that outgrew a mapping tool but needs no intelligence at all. If a competent engineer can write the rules down completely, you don’t need a model in the loop — you need the rules, in a repo, with an owner.

When the agent tier is actually warranted

The heavy tier — an agent driving MCP tools — earns its cost when judgment is the work: reading context, applying policy that resists complete rule-writing, deciding, escalating. Built properly, it means narrow typed tools rather than raw API access, approval gates on consequential writes, idempotency on everything, and logs that can reconstruct any decision after the fact. That machinery is why it costs what it costs, and it’s worth it when a human currently spends hours a day doing that triage — not before.

Our honest position, as the people who sell the top tier: most companies that come to us for an agent should start one tier lighter, and we tell them so. The expensive mistake isn’t choosing Zapier or choosing agents — it’s skipping tiers in either direction: an agent where a script would do, or 23 zaps where judgment was needed all along. When a workflow genuinely needs the heavy tier, that’s what we build and run — the tools, the gates, the logs — as a system someone owns.