Counting operations before they count you
Make charges you one credit every time a module does something. Zapier charges one task every time an action succeeds. Neither of them charges for the thing you actually care about, which is an order arriving or a lead reaching the CRM. They charge for how many boxes the logic passes through on the way there, and that is a number you have every engineering reason to let grow.
What the meter counts
Make's pricing page defines a credit as one module action: adding a Google Sheet row, fetching Gmail account data, each one costs a credit. The Free plan gives you 1,000 per month. Core starts at $12 a month for 10,000 credits, Pro at $21 and Teams at $38 for that same 10,000. Credits expire at the end of the term. Run out before the cycle resets and you buy more in bundles of 1,000 or 10,000 at the fixed rate in your subscription, or you turn on auto-purchase and stop watching.
Zapier counts the same shape with different vocabulary. A task burns when a Zap successfully completes an action, and Zapier does not charge for triggers or for polling, which is a real kindness and worth saying out loud. The Free plan allows 100 tasks a month on two-step Zaps. Professional starts at $19.99 a month, Team at $69 for 25 seats. Cross your tier ceiling and Zapier either switches you to pay-per-task billing at a rate higher than your subscription rate, or pauses your Zaps until the next period.
Both of these are honest, legible pricing models. That is not the problem. The problem is what they are a function of. Your bill does not move with how much business you did. It moves with how many discrete boxes your diagram contains.
Multiply by steps, not by orders
Take a scenario that handles incoming orders. It validates the payload, looks up the customer, branches on region, writes to the warehouse system, writes to the ledger, and posts a line into Slack. Six module actions. At 100,000 orders a month that is 600,000 credits. Now your finance lead asks for a tax lookup before the ledger write. Seven actions, 700,000 credits. Order volume did not change at all.
The part that stings is what this does to your instincts. Splitting one overloaded module into two readable ones now has a price. Adding a guard clause has a price. Make's Code App lets you fold several steps into JavaScript or Python, but it meters that at 2 credits per second of execution time, so you have traded a step counter for a stopwatch. Every engineer who has worked on a mature Make scenario has at some point built something worse on purpose to keep the credit count down.
When we took Stay World Class off Webflow and Xano and onto Next.js, NestJS and Supabase, the workflow logic was the part that changed character most. It stopped being a diagram you paid to extend and became functions you could add to for free and, more to the point, write tests against. The migration itself ran as a four stage ETL that mapped every legacy ID onto a PostgreSQL UUID. The numbers people noticed were Lighthouse moving from 55.91 to 91 out of 100 and LCP arriving 77% faster.
The same six steps as a queue consumer
Cloudflare Queues bills per operation, where an operation is each 64 KB written, read or deleted. Delivering one message normally takes three of them: a write, a read, a delete. So those 100,000 orders come to 300,000 operations. The Workers Paid plan includes 1,000,000 operations a month before charging $0.40 per additional million, which puts the whole month inside the included allowance. You pay the $5 Workers Paid minimum.
The six steps still happen. They run inside the consumer as ordinary function calls, and nothing counts them. Workers bills 10 million requests and 30 million CPU milliseconds a month on that same $5, then $0.30 per extra million requests and $0.02 per extra million CPU milliseconds. Crucially it does not bill for duration at all, only for CPU, so six steps that mostly sit waiting on someone else's API cost you close to nothing. The seventh step is free. So is the fortieth, and so is the refactor that turns one of them into three.
None of this makes the queue version simpler to build. It makes the cost of the system stop being a function of its internal structure. That is the trade you are making: more setup once, in exchange for a bill that only tracks volume.
When paying per operation is the right answer
If you run 2,000 tasks a month, Zapier Professional at $19.99 costs less than an hour of anyone's time and it will keep costing less forever. There is no version of this argument where that math flips. Low volume and a low step count means the multiplication never gets large enough to be interesting, and you should go do something else with your afternoon.
If the people who own the automations are not engineers and they change them most weeks, the visual builder is the product you are buying. Losing it to save money on operations is a bad trade. Same story when the integration you need is already one of Make's 3,000 connectors and writing an OAuth client against a poorly documented vendor API would eat three days.
The case for moving is narrower than it sounds. It applies when your step count is high, your volume is high, and the logic has become the kind of thing you want covered by tests rather than by a screenshot of a diagram. If that is not you, stay where you are. The meter is only a problem once it starts charging you for thinking clearly.
