Zapier/Make vs. Custom Automation: Cost Is the Wrong Reason to Switch

Task-based pricing does not punish you at scale. It rewards you, and the numbers are published where anyone can check them.

On Zapier's Professional plan, billed annually, 750 tasks a month costs $19.99. That works out at 2.67 cents a task. At the top of the same slider, 100,000 tasks a month costs $489, which is 0.49 cents a task. Same plan, same features, and a unit price that has fallen by a factor of 5.4 on the way up.

The total bill rises, obviously. It goes from $19.99 to $489. But that is 24.5 times the money for 133 times the volume, which means your cost per unit of work drops every single time you move up a tier. Nearly every article arguing that you have outgrown Zapier gets this backwards, and none of the ones I read had gone and looked at the ladder.

Here is the number that ends most of these debates. A hundred thousand tasks a month, which is a serious amount of automation for a mid-market ops team, runs $5,868 a year. That is less than one of our two-week sprints, once, and it renews at a price you can predict.

Overages, and almost nothing else.

Zapier prices monthly self-serve overage at 2.5 times your base rate, and annual self-serve at 1.25 times. There is a pause ceiling that stops the meter at three times your subscription until the next cycle, which is a real mercy and also a warning about what it exists to contain.

So the way a Zapier bill actually hurts you is not the plan you chose. It is one workflow in a retry storm, or a trigger firing on every row of a spreadsheet somebody just bulk-imported, billing at 2.5 times until it slams into the ceiling. That is a reliability failure wearing a billing costume, and rebuilding in code does not fix it by itself. Bad logic burns money on any substrate.

One more thing worth checking before you conclude the tool is expensive. Zapier's annual rate is about a third below its monthly rate at every tier I compared, $19.99 against $29.99 at the bottom and $489 against $733.50 at the top. Plenty of teams are paying the monthly premium on a workflow they have run without interruption for two years. Fixing that is a five-minute job and it is the cheapest saving available to you.

This is where most comparisons quietly fall apart, including the one in the earlier version of this post.

Zapier bills a task only when it successfully completes an action. Triggers do not count, polling does not count, and the built-in tools do not count either, so Filter, Paths and Formatter steps are free. Make bills a credit for every module that runs, including the trigger and including the data transforms.

Run the same six-step workflow through both and Zapier bills you for three, Make bills you for six. Any comparison that puts a Zapier task next to a Make credit and declares a winner is comparing two different units of account.

Make's paid plan starts at $9 a month for 5,000 credits. Zapier Professional wants $89 a month for 5,000 tasks on annual billing, or $133.50 if you pay monthly.

Correct for the unit difference and the gap narrows, but it does not close. Five thousand Make credits buys about 833 runs of that six-step workflow, so roughly 1.1 cents a run. Five thousand Zapier tasks buys about 1,666 runs of the same thing, so roughly 5.3 cents a run. That is Make coming out around five times cheaper per run, and I have deliberately used Zapier's discounted annual rate to make its side of the comparison as strong as it goes.

I sell custom automation and I am telling you that if your only complaint is the invoice, the answer is a cheaper platform, not a build. Switch to annual billing. Move the high-volume workflows to Make. If the workflow is personal and read-only, the new free agent workspaces may cost you nothing at all. Both of those cost you a weekend, and both of them beat writing me a check.

Here is the part worth paying attention to, because this is where the honest case for custom lives.

Zapier's autoreplay retries a failed step up to five times, backing off at 5 minutes, 30 minutes, 1 hour, 3 hours and 6 hours. That is about ten and a half hours of cover for a flaky upstream API, which is a genuinely decent safety net. It is also gated: Professional plan and above, not Free. Reliability is a paid feature, and that is a legitimate product decision rather than a scandal.

But read the exclusions. Runs sitting on hold are skipped, and held is the status Zapier uses when a webhook misbehaves or sends more data than expected. Filter and path steps are never replayed at all, and Zapier is explicit that those conditions do not get re-evaluated even when retrying an earlier step would have changed them. So a run that was filtered out on bad data stays filtered out after you fix the data.

Then there is the threshold that made me sit up. Zapier automatically switches a Zap off when it errors on 95 percent or more of its runs over the last seven days. Ninety-five percent. A Zap failing four times out of five is not broken enough to trigger that, so it stays on, quietly dropping one record in five, for as long as nobody looks. Changing that threshold is a setting Zapier reserves for its Company plan.

An OAuth token expires. A trigger stops firing. Somebody renames a field in your CRM. And the Zap simply has not run in two weeks.

That description comes from a thread on Zapier's own community forum where builders compare notes on exactly this, and the detail that matters is that these produce no error. There is no failed run, because there is no run. Nothing lands in your history, nothing trips an alert, and the first person to notice is usually your customer.

This is not a defect and I want to be fair about it. No system can raise an alarm about an event that never arrived unless somebody first told it what normal looks like. Expected-volume monitoring is the missing piece, and it is missing from every no-code tool I have used, not just this one.

The workaround the good Zapier operators build is a heartbeat that alerts on silence rather than on error. Every Zap that matters writes a timestamped row to one shared table, and a scheduled Zap reads that table each morning and flags anything whose last run is older than its own interval. It works. It genuinely does. But look at what you just built: monitoring infrastructure, hand-rolled, running inside a platform that bills you per task to operate it, maintained by whoever on your team understands it. At that point the no-code argument has quietly become a build-versus-build argument, and you are on the losing side of it.

Zapier guarantees a maximum of 60 days of Zap run data and displays up to 10,000 runs, and its documentation tells you to export your history regularly if you need records beyond that.

Sit with what that means operationally. A customer disputes a charge in June that was processed in March. A supplier insists they never received a purchase order. An auditor wants to see which records the system touched last quarter. In every one of those, the answer from your automation layer is that there is no answer, and there was never going to be.

The 10,000-run cap bites sooner than the 60 days does, incidentally. A workflow running 500 times a day fills it in under three weeks.

This is the argument I find most people have never considered, and it is the one that decides it for finance, compliance, and anything touching money. Owning your logs is not a nice-to-have on those workflows. It is the job.

Open your Zapier dashboard and export the run history. Then put every workflow you own into a table with three columns, and be honest in the third one.

First column, runs per month. You already have this. Second column, what one silent week costs you, in money or in hours spent reconstructing what should have happened. Not a broken week, a silent one, where it looked fine on the dashboard and did nothing. Third column, a yes or no: if somebody asked you to prove what this workflow did 90 days ago, could you?

Most lists split hard and fast. There is a long tail of low-stakes conveniences where a silent week costs you an apology and nobody will ever ask about last quarter. Those belong in Zapier or Make forever, and ripping them out to prove a point is how you burn a budget. Then there are two or three rows where the second column has a real number in it and the third column says no. That short list is the entire conversation.

If your table has no rows like that, you do not need custom automation yet. Anyone telling you otherwise is quoting from a services page.

AgentClaw's current numbers separate projects from executive ownership. A Starter build is $1,500 to $2,500 fixed. A Production sprint is $5,000 fixed for one full workflow live in about two weeks. CAIO Core is From $5,000/month with builds separately scoped; CAIO + Delivery is From $10,000/month with one active delivery stream. None of those prices turns custom delivery into a cheaper Zapier plan.

Against the cited $5,868 annual Zapier example, the platform wins on throughput price for many deterministic workflows. The decision changes only when workflow fit, consequence of silent failure, evidence, integration and operating ownership justify custom work.

Custom automation is code, and this strict ICP has no employee who writes software, firmware or embedded code. The external delivery and exit path therefore matter. Software developers had a 2025 median wage of $135,980 in Bureau of Labor Statistics data published through O*NET, but that labor statistic does not prove that a reader should hire or build.

Use the company's own baseline and acceptance evidence. When one silent week has a material consequence or the company must reconstruct what happened, a custom agent evaluation may be justified. Otherwise keep the simpler platform or manual process.

AgentClaw serves a non-software company where no employee writes software, firmware, or embedded code. For that audience, a custom route means externally delivered work with a named internal process owner, acceptance evidence, and an exit path. It does not mean asking an internal software team to maintain a one-off build.