Make at scale: the operation counter is the architecture

Make's pricing has an unusual property: it makes bad design visible. Every module execution is an operation, every operation is billed, so a scenario that fans out where it should filter shows up on an invoice rather than in a profiler. That is a gift, if you read the counter.

Here is what we change first when a Make account has grown past its plan.

1. Filter before the iterator, not after

The classic shape is: fetch 500 records, iterate, filter inside the loop, act on the eight that match. That is 500 iterations plus 500 filter evaluations plus 8 actions, and you paid for 992 operations to do 8 things.

Almost every source module supports a search or query parameter. Fetching the eight records in the first place turns the same scenario into 17 operations. When the source genuinely cannot filter, filter immediately after the iterator and before anything else — the difference between a filter in position two and position five is three operations per item, multiplied by the list length, every single run.

2. Aggregators are how you stop paying per item

If the outcome is one email summarising forty rows, an Array Aggregator after the iterator collapses forty downstream paths into one. Teams often build the loop first and never revisit it, and end up sending forty API calls where the target API has a bulk endpoint.

The rule of thumb: after an iterator, look at every module downstream and ask whether it genuinely needs to run per item, or whether it needs to run once with all the items. Usually it is the second.

3. Scheduling is a cost lever people forget

A scenario polling every minute for something that happens twice a day costs 1,440 runs a day to do two things. If the source can push, use a webhook and pay for the two. If it cannot, poll on a schedule shaped like the business — every fifteen minutes during office hours and hourly overnight is a ninety percent cut that nobody will notice.

4. Error handlers stop the silent double-charge

Without an explicit error route, a failed module in the middle of a scenario leaves the run incomplete and, with auto-retry enabled, re-executes the modules that already succeeded. That is both duplicate side effects — the second invoice, the second Slack message — and double operations.

Put an error handler on any module that touches an external API, decide explicitly between Resume, Break and Commit, and route the break to a queue you can inspect. This is the same idempotency problem every automation platform has; we wrote it up generically in retries, idempotency and dead letters.

5. One scenario per business event, not per integration

The most expensive Make accounts we have seen were expensive structurally: thirty scenarios where each pair of systems got its own, so a single customer signup triggered six scenarios, each re-fetching the same customer record.

Model the event, not the wiring. One scenario triggered by "customer created" that fans out to the CRM, the billing system and the welcome email costs one fetch instead of three, and — more valuable than the money — it gives you one place to look when the signup flow misbehaves.

When to stop optimising and move

There is a crossover. If after these five passes the account is still above roughly a million operations a month, the scenarios are engineering artefacts maintained by engineers, and the bill is in the thousands, you are paying a premium for a canvas your team no longer needs. That is the point to price self-hosted n8n or a small service in your own stack against it. Below that line, Make is cheaper than the person who would maintain the alternative.

What to do this week

Sort your scenarios by operations consumed in the last 30 days and open the top three. In each one, find the iterator and count how many modules sit downstream of it. That number, times the average list length, is your bill — and it is usually the fastest thing in the whole account to cut in half.