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. Zapier's free plan includes 100 tasks a month and Pro starts at 750, and triggers, filters, formatter and path steps don't count as tasks, so at this size the bill 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 real 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 now offers AI by Zapier steps that can classify a ticket or extract fields, and for a single, low-stakes sorting decision that's often enough. What it doesn't give you is the rest of the harness: a test set the classifier has to pass, approval gates on consequential actions, and a record of why each decision went the way it did.
• State across steps. “If they haven't replied in five days, and their plan is annual, and we already sent one reminder.” Zapier holds that state in Delay steps, Storage and helper tables, 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. Every successful action step is a task. A four-action zap running 5,000 times a month is 20,000 tasks, which on Zapier's published pricing is $189 to $373.50 a month depending on plan and billing; 50,000 tasks runs $289 to $598.50. A small scheduled worker doing the same job typically costs a few dollars a month to host.
• 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 won't do. Zapier itself only guarantees 60 days of Zap run history, displays up to 10,000 runs, and suggests exporting regularly if you need longer records.

The failure pattern has a shape we've seen enough to name: zap sprawl. One company we worked with, 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 is an outage waiting for a date.

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 scheduled GitHub Actions workflow or 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 close to zero marginal cost, and it beats both a $500-a-month zap tangle and a premature agent. Pick the scheduler with open eyes: GitHub notes that scheduled runs can be delayed during periods of high load, run at most every five minutes, and are disabled automatically in public repositories after 60 days without activity. For anything time-sensitive, a small always-on worker is the safer home.

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 and 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. Before that point, it isn't.

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 is 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, with the tools, the gates and the logs, as a system someone owns.

Sources

• Plans & Pricing, Zapier
• View and manage your Zap history, Zapier Help Center
• AI by Zapier: Easily add AI steps to your workflows, Zapier
• Events that trigger workflows (schedule), GitHub Docs