Agent vs Zapier TCO: workflow-automation economics across four scale tiers.

The agent vs Zapier TCO question is the workflow-automation decision most teams get wrong — not because the answer is hard, but because the brochure economics rarely match the lived ones. Three paths, three cost structures, three break-even curves. The right choice is decided by run volume and change cadence, not by which vendor has the better landing page.

Zapier wins the long tail — low volume, broad integration, near-zero build cost. Make.com wins the mid-tier — modestly higher build effort, sharper per-action pricing, better long-running workflow support. Custom agentic builds win the head — high build cost, marginal cost approaching zero, and the only path that survives a change-cadence stress test at scale. Most real-world stacks blend all three.

This guide is the worked TCO across all four tiers — 1, 10, 100, and 1,000 workflows — with the change-cost variable surfaced explicitly because it is the line item that decides most decisions and that no vendor calculator includes. Numbers are calibrated against a real 50-workflow agency migration that paid back in eight months.

Every workflow-automation conversation starts in the same place: should we Zap it, should we build it, or should we drop to Make.com? The right framing is not which tool is best — all three have legitimate roles — but which cost curve matches the workload. The three paths have meaningfully different economics, and the crossover points are where most decisions go wrong.

Zapier is the no-code default. Workflow setup measured in minutes, per-task pricing that scales linearly with usage, the broadest third-party integration library in the category. The cost curve is flat at the bottom and steep at the top. Make.com sits one rung below — visual builder, per-action pricing rather than per-task, stronger primitives for long-running and conditional workflows. Custom agentic builds are the engineering path — weeks of build cost, near-zero marginal cost per run, and the ceiling that actually matches enterprise scale.

The decision rarely comes down to a single workflow. Most real stacks are hybrids — Zapier handling a hundred low-volume utility automations, Make.com running the medium-cadence orchestration layer, and a custom agent handling the two or three hot paths that drive most of the throughput. The right question is per-workflow, not per-vendor: which class does this automation belong in, and what does that imply for the next ten like it.

Build cost is the most visible line item and the one the brochure economics get right. A Zapier workflow is genuinely a 15-minute job — pick a trigger, pick an action, map a few fields, turn it on. A Make.com scenario is hours to a day or two for anything beyond a simple connect-the-dots. A custom agentic workflow with proper integration, observability, error handling, and tests is weeks of engineering for the first one and days for each marginal addition on the same stack.

The trap in this category is treating build cost as a sunk cost. It is — for the workflows that never change. But automation workflows do change, and the time-to-modify is closely correlated with the time-to-build. A Zapier workflow that took ten minutes to build takes ten minutes to modify. A custom workflow that took a week to build can take a day to modify. That asymmetry compounds.

One implication worth lifting out. The custom-build curve is non-linear. Workflow one is expensive because you are building the runtime; workflow two is half the cost because the runtime is already paid for; workflow ten is days. By workflow fifty, the marginal build cost on a mature custom stack is competitive with Make.com for anything beyond trivial scenarios. The decision has to consider the second workflow, not the first.

The opposite applies on the no-code side. The hundredth Zapier workflow takes exactly as long as the first, because there is no shared runtime to amortise across. What scales linearly on the way up scales linearly on the way down — every change to every workflow is the same cost, every time.

Run cost is where the curves diverge most sharply. Zapier prices per task — every action in a workflow is a task, every multi-step workflow consumes multiple tasks per run. Make.com prices per operation, which is similar but typically lands at 30-50% the per-run cost of an equivalent Zap. Custom agents price as LLM tokens plus a few cents of compute and storage — typically measured in fractions of a cent per run for non-AI workflows and single-digit cents for AI-augmented ones.

The right way to compare is not by sticker price but by cost per workflow per month at a representative run volume. The matrix below shows a typical three-action workflow at three monthly volumes — the level where most real-world ops automations actually live.

The shape worth internalising: Zapier is cheap below the threshold and expensive above it, with no in-between. Make.com is the mid-volume flat spot. Custom is expensive at the low end and cheap forever once you cross the build-cost recovery point. The decision is not which tool is cheaper per run — they are all cheaper than the others at some volume — but which volume your workflow actually runs at.

Build cost and run cost dominate every TCO calculator we have seen. Change cost is the line item nobody includes, and it is the one that decides most real outcomes. A workflow is not built once — it is changed, on average, four to six times per year as the underlying business processes evolve. That is the variable the brochure economics never surface.

Change cost has three components: the time to modify, the risk of a bad change reaching production, and the operational overhead of maintaining a fleet of workflows. Each scales differently across the three paths, and the differences compound brutally as the workflow count grows.

The pragmatic way to price change cost into a TCO model is to assume each workflow is modified five times per year and multiply by the per-change time. At workflow scales above 100, add a fleet-overhead line that scales linearly on no-code (~10% of an FTE per 100 workflows) and sub-linearly on custom (~10% of an FTE per 500 workflows on a mature stack). Those two additions usually flip which path is cheapest at any scale beyond mid-volume operation.

The four-tier model below collapses build, run, and change cost into a single 24-month TCO figure per workflow tier. Each row assumes the three-action workflow profile from Section 03, running at the median monthly volume for that tier, modified five times per year. Numbers are blended South African and US engineering rates and May 2026 vendor list pricing.

The pattern is clear enough to memorise. At tier 1 (a single workflow), Zapier wins by an order of magnitude. At tier 10 (ten workflows, mid-volume), Make.com is the right default — Zapier is still close, custom is still too expensive. At tier 100 (a hundred workflows, high volume), the custom path crosses below no-code and stays below it. At tier 1,000, the custom advantage is roughly 5× — the build cost is fully amortised and marginal cost dominates.

The numbers vary by workflow profile — a workflow that hits a simple webhook costs less than one that pulls a CRM record, transforms it, calls an LLM, and writes back. But the curve shape is robust. We have run this model against half a dozen client workloads with very different per-workflow profiles, and the crossover points land within roughly a factor of two of the tiers above in every case.

The crossover between no-code and custom is decided by two variables that work together: the total number of workflows, and the average monthly run volume per workflow. The break-even surface is a curve, not a line — neither dimension alone gives the answer.

The rule of thumb that emerges from the model: custom becomes the cheaper path when either workflow count exceeds roughly 500 or run volume exceeds roughly 1 million per month for a hot-path workflow. Below both thresholds, no-code wins on TCO. At either threshold, the math is close enough that the qualitative factors — change cadence, governance, AI features — should decide.

The qualitative factors that flip the math earlier than pure TCO suggests: AI features that are awkward to express in iPaaS, governance and audit requirements that demand version control, data-residency constraints that rule out US-based iPaaS vendors, and integration with internal systems that no third-party connector covers. Each of these can pull the break-even point down from 500 workflows toward 50 or even 10. Pure cost is rarely the full story.

The migration patterns in this section come from a real client engagement — a mid-sized marketing agency with roughly 50 active Zapier workflows accumulated over four years. The combined monthly Zapier bill had crossed $3,000 and the operations team was losing most of a day each week to maintenance, debugging, and the occasional silent failure. The brief: cut cost without losing workflows, improve reliability, and create the runtime for the next 50.

The migration ran across eight months and paid back the engineering investment in roughly that same window. The pattern below is the playbook we use on every similar migration.

The economics of the migration: an upfront engineering cost roughly equal to ten months of the original Zapier bill, a steady-state Zapier bill cut to less than 15% of the original (one starter tier subscription), and a custom-stack run cost of roughly $80 per month for the migrated workflows combined. Payback came in month 8; from month 9 onward the saving runs at over $2,500 per month, before any account of the operational time recovered.

Two operational gains that did not show up in the cost model mattered as much as the bill cut. First, change cost dropped sharply — modifying a migrated workflow now happens through the same PR workflow as application code, with proper review and instant rollback. Second, the agency now ships AI-augmented workflows that were impossible on Zapier — LLM-driven lead scoring, generative email drafting, multi-step research agents — on top of the same runtime, with marginal build cost. The runtime is the gift that keeps giving.

We have shipped variations of this pattern across half a dozen agencies and mid-market clients, all of which fed back into the CRM automation engagements that anchor most of our build work. The migration math is consistent across engagements when the model assumes 24 months of TCO and includes change cost — both of which most internal calculators miss.