What a metered automation stack actually costs, and what it costs once it isn't metered.

A twelve-client US marketing agency, four years into an automation estate nobody planned.

The subject is constructed, but not freely invented. Its parameters are set to match cases that are on the public record, because an example tuned to flatter the conclusion would be worthless. Where I have chosen a number, the reasoning is stated and you can substitute your own.

Sources for the comparison cases: Softomate, Zapier Pricing 2026: The Real Cost at Scale; US Tech Automations, Marketing Agency Automation Cost Guide 2026. Both are secondary trade sources, not audited figures; see Assumptions and limits.

Three platforms, three different meters. The arithmetic changes, not the work.

Everything in this document follows from one fact: the three platforms count different things. Nobody is being overcharged and no pricing page is misleading. The workflows are identical; the unit of billing is not.

How this example was produced.

• Inputs are constructed and declared. Every workflow in the inventory carries the volume assumption behind it in the same row. Nothing is averaged into a total you cannot take apart.
• Prices are public and dated. Zapier's and Make's tier tables were read from the pricing data those pages themselves render from, rather than transcribed by eye, because two separate readings of the rendered Zapier table disagreed with each other. n8n's licence terms are quoted from the licence file in its own repository.
• The counting rules are the vendors' own words, quoted above, not a summary of them.
• The arithmetic is mechanical. Volumes drive a tier lookup against the published ladders; the tier sets the price. There is no judgement between the inventory and the cost.
• Judgement is confined to two places, and both are flagged where they occur: the volume assumptions, and the estimate of incremental maintenance labour. The second is the weakest number in the document and is given as a range.
• What is not modelled: migration labour is quoted as effort, not capitalised into a payback period; no discount rate; no allowance for the workflows a four-year-old estate contains that nobody uses any more.

Every workflow, and the volume assumption behind it.

Grouped by function. Runs/mo is how often the workflow fires; billable steps is how many chargeable actions each run performs. Their product is the monthly task or credit consumption. The allocated cost against each group heading uses the marginal rate of the tier actually being paid for: $0.00500/task on Zapier and $0.00194/credit on Make.

Continued.

Continued.

Where the money actually is.

This is the finding that changes what a migration should do first, and it is invisible from inside the platform's own billing screen, which reports a single account total. It is also the reason a migration priced per workflow is priced on the wrong unit.

Volume drives a tier. The tier sets the price. Neither is negotiable at this size.

Zapier's Team plan is used rather than Professional because published agency guidance puts the crossover at 4+ client accounts, where shared connections and multiple seats stop being optional. Make's Teams plan is used for the same reason. Both are priced on annual billing, the cheaper basis and therefore the harder one to beat.

The same 85,698 runs a month, counted once each instead of 3.88 times.

Self-hosted n8n Community edition is free, and it is documented as “self-hosting with almost the complete feature set”. The per-execution meter is not merely cheaper. On the self-hosted edition it does not run at all. The variable cost of a workflow run goes to zero, and what remains is server rent and labour.

On throughput there is no question at this size. n8n documents “up to 220 workflow executions per second on a single instance”, benchmarked on a 4 GB machine. The subject needs 85,698 executions a month, which is under 0.0331 per second on average. The vendor benchmark uses a trivial two-node workflow, so it is a ceiling and not a promise, but the margin here is four orders of magnitude, and the sizing above is set by comfort, not by load.

What the end state costs, including the parts that stay where they are.

This is not a “move everything” number. It is the cost of the recommended end state, which keeps three workflows on Zapier, deletes two outright, and moves the rest. Both of those decisions are argued on the next page but are priced here, because a saving that assumes a migration nobody should do is not a saving.

Against monthly billing rather than annual, the same end state saves $15,365–$18,845 a year. The published range for migrations of this kind is a 60–90% cost reduction; this example lands at 56–79% on the harder billing basis, inside that band and not at the flattering end of it.

The order to move them in, and what each wave actually costs in effort.

Ordered by risk-adjusted payback, not by size. The rule applied throughout: learn the platform on work that cannot hurt a client, and move the revenue-critical workflows last, in parallel, with reconciliation. Effort is build days for one experienced engineer and excludes the agency's own testing time.

Five things in this estate that should not move, and one that should be deleted.

A teardown that recommends migrating everything is a sales document. The per-execution meter is not free of consequences, and for some workflows the honest answer is a native feature, a cheap purpose-built tool, or leaving it exactly where it is. In this example that verdict applies to 5 named workflows; a sixth line is a question to settle before migrating, and the last is a rule rather than a workflow.

There is a sixth case worth stating even though it does not arise here. If an agency's entire automation bill is under roughly $7,000 a year, no honest teardown of it clears $5,000 in savings, and the recommendation is to stay on Zapier and spend the attention somewhere with more in it. The guarantee exists so that finding that out costs the agency nothing.

What this document cannot establish.

Stated in the same terms I would state them to a client, because the limits are the part of a costing that is usually missing.

• The subject is constructed. Its client count, workflow inventory and every volume figure are mine. They are chosen to sit near documented cases, but no real agency has this exact estate, and none was consulted. Nothing here is a client result.
• The volume assumptions are the largest uncertainty by far. The prices are exact and the arithmetic is mechanical, so the entire result rests on figures like “850 leads per client per month”. Real inventories are read from the platforms' own task-history exports, which removes this uncertainty completely. It cannot be removed here.
• Maintenance labour is an estimate, and the weakest number in the document. It is given as a range for that reason. If the agency has nobody who can own a server, the honest figure is higher than the top of that range, and the recommendation may change.
• Migration effort is estimated, not quoted. Days assume one experienced engineer with clean access. Credential and OAuth access across 12 client accounts is the most common cause of schedule slip and is largely outside the engineer's control.
• Prices change. Every figure is a public list price on 7 September 2026. Both platforms have repriced before. Enterprise pricing on all three platforms is not published, so an agency with a negotiated contract will not recognise these numbers, and should substitute their own, which the structure here allows.
• n8n Cloud prices are shown in the currency served to the retrieving IP address (GBP). n8n prices per region rather than converting, so a US buyer will see different figures. No US-dollar n8n Cloud price is quoted anywhere here because I could not retrieve one.
• The two comparison cases are trade sources, not audited figures. The £400→£1,200 and ~$3,000/month cases come from vendor and consultancy blog posts. They are used to set the subject's scale, not as proof of anything about a real agency.
• No behavioural change is modelled. Workflows are assumed to run at the same frequency after migration. In practice teams build more when runs stop being metered, which erodes some of the saving, and is usually a good thing.
• Not modelled at all: the staff time the current estate consumes, the delivery risk when a workflow fails silently, data-egress charges, VAT or sales tax, and any cost of the agency's own people participating in the migration.
• This is not legal advice. The note on n8n's licence terms quotes the licence and identifies a boundary. It does not interpret it for any particular business model.

Every price in this document, and where it came from.