Zapier sprawl to Temporal: a 51-person shop's €2,120 cut

The clearest sign that your Zapier stack has gone wrong is this: the operations lead can no longer say, in one sentence, what happens when a customer places an order.

For one of our clients in Almere, that sentence used to take seven minutes and a whiteboard. A Shopify order fired a webhook into Zapier. Zapier handed it to a Make scenario that decided whether the SKU lived in the main warehouse or the 3PL in Venlo. The 3PL branch routed through a separate n8n workflow on their hosted instance. The express-shipping upgrade triggered a Pipedream pipeline that wrote a row to Airtable and pinged a Slack channel. Customer-facing email was Klaviyo. Finance sync to Exact Online lived inside a fifth tool that nobody had logged into for eleven months.

Four automation SaaS bills. Three flavours of YAML-or-not-YAML. One ops lead, on a Sunday night, asking why 47 orders had vanished somewhere between Shopify and the picking station.

This post is what we did about it, and what the bill looked like ninety days later.

The four-tool sprawl, in money

The operator runs 51 people, mostly warehouse and customer service. Their monthly automation bill in March 2026 broke down roughly like this:

• Zapier Company plan, ~100k tasks: €1,520
• Make Pro, ~80k operations: €340
• n8n Cloud Team: €240
• Pipedream Business: €180

Total: €2,280. Round it to €2,300. They had been quietly above €2,000 for thirteen months. Every Black Friday it jumped to €4,400 because Zapier and Make both bill on a usage curve that punishes the months you actually need them to work.

None of this was anyone's fault. They had hired their first ops lead in 2022, picked Zapier because the agency they were using picked Zapier, then added Make a year later because the agency that came after picked Make. Each tool solved a real problem at the moment it was introduced. Nobody had ever been paid to delete the previous one.

Why Zapier scales the wrong way for an order-driven business

Zapier prices on tasks. A task is roughly one step in a Zap. A single Shopify order with four line items, an inventory check, a routing decision, a 3PL handoff, an email, and an accounting hook can easily fire eight tasks. Multiply by 30,000 orders a month and you sit at 240,000 tasks, which puts you firmly inside Zapier's Company tier. Every percentage point of revenue growth multiplies the bill.

That is fine when you are spending €80 a month and trying to get something to work. It stops being fine somewhere around €1,000 a month, which is when the same money would have hired a freelancer to write the workflow in code.

The other problem is invisible failures. When a Zap dies, you get an email. If you have 280 Zaps and 14 of them throw harmless-looking warnings every day, you stop reading the emails. The Sunday-night incident that brought us in was a Zap that had silently turned off two weeks earlier because Shopify changed a webhook payload field. Forty-seven orders had landed in Shopify, never made it to the warehouse, and the customers were starting to notice.

Why Temporal, specifically

We looked at three options. Self-hosted n8n, which would have cut the bill but kept the same operational shape. Inngest, which is a clean fit for event-driven JavaScript but did not match the team's existing TypeScript backend conventions. And Temporal, which is what we picked.

Temporal is a workflow engine. You write workflows as ordinary functions in TypeScript, Go, Python, Java, or .NET. The framework persists every step the function takes, so if a worker process crashes mid-flight, another worker picks it up at the exact line it stopped. If an external API returns a 502, the workflow retries with whatever backoff policy you wrote. If you redeploy the worker, in-flight workflows continue against the new code where it is safe and against the old code where it would change history.

Three properties mattered for this operator.

The first is durable execution. The Sunday-night problem of "the Zap silently stopped" cannot happen in the same way, because a Temporal workflow is either running, completed, failed loudly, or paused on a timer that you can see in the UI.

The second is replay. When something breaks, you can re-execute a failed workflow against the current code without writing a custom recovery script. That alone removed an entire category of one-off Slack rescue threads from the ops lead's week.

The third is predictable cost. You pay for compute, not for events. The operator now runs four small workers on a Hetzner CCX13 cluster, plus a Temporal Cloud namespace on the Essentials tier. That is the €180 bill.

The first workflow we moved

We picked order-to-fulfillment first because it touched everything that was already breaking: Shopify, the warehouse picking system, the 3PL EDI feed, Klaviyo for customer email, and the Exact Online accounting hook. If we could move that one workflow and survive a week, we could move the rest.

Here is the workflow function, simplified to fit on the page.

import { proxyActivities, sleep } from '@temporalio/workflow'
import type * as activities from './activities'

const {
  reserveStock,
  routeFulfillment,
  notifyCustomer,
  postToAccounting,
  flagForManualReview,
} = proxyActivities<typeof activities>({
  startToCloseTimeout: '30 seconds',
  retry: { maximumAttempts: 5, initialInterval: '2s' },
})

export async function orderWorkflow(order: ShopifyOrder) {
  const reservation = await reserveStock(order)

  if (!reservation.ok) {
    await flagForManualReview(order, reservation.reason)
    return { status: 'manual_review' }
  }

  const route = await routeFulfillment({
    order,
    carrier: reservation.location === 'venlo' ? '3pl_venlo' : 'in_house',
  })

  await notifyCustomer(order, route)

  // Wait up to 24h for the warehouse to confirm picking
  await sleep('24 hours')

  await postToAccounting(order, route)
  return { status: 'done', route }
}

Everything that actually talks to the outside world lives in the activities file. The workflow function is deterministic. It does not call Date.now(), it does not generate random numbers, it does not read environment variables. If it needs a timestamp, it asks an activity for one. That constraint is the price of replay, and it bites when you migrate code from Zapier or Make, because those tools encourage you to do exactly the opposite.

The migration approach

We used the standard strangler fig. The Zapier and Make scenarios stayed online. We pointed a copy of the Shopify webhook at a small Express server in front of Temporal. For one week, we ran both paths and compared outputs in a third script. When the new path produced the same result for 100% of orders over five business days, we swapped the webhook target and turned the Zaps off one route at a time.

This took eleven calendar weeks for the full migration. Four workflows shipped in the first three weeks. The long tail was finance edge cases, returns handling, and a particular VAT scenario for German customers that the previous setup had been quietly getting wrong since 2024.

What broke, honestly

Three real gotchas, in the order we hit them.

Idempotency was an afterthought

Temporal will retry activities. Sometimes it will retry an activity that actually succeeded but failed to acknowledge the success. If your postToAccounting activity creates a new invoice in Exact Online every time it runs, you are about to have a bad month. Every external write needs an idempotency key, usually the workflow ID plus a step name. We added this to Klaviyo, Exact, and our warehouse system. The warehouse system did not support it, so we wrote a thin proxy that did.

Worker pool sizing is not obvious

Default worker concurrency assumes your activities are fast and your workflows are short. The 3PL EDI activity took 8 to 30 seconds depending on time of day. Our first Black Friday rehearsal queued 4,000 workflows behind a worker pool sized for office hours. We split workers by task queue (one pool for warehouse activities, one for finance, one for email) and the queue depth went back to single digits.

Workflow versioning bites at deploy time

If a workflow is running when you change the code, replay can fail because the new code takes a different branch than the old code did. Temporal's versioning API handles this, but you have to actually use it. We learned this the way most teams learn it: by breaking three in-flight workflows on a Wednesday afternoon and explaining to the ops lead what "non-deterministic error" means.

The Wednesday in question: three orders sat paused inside the 24-hour sleep call. The deploy added a second SMS notification after the email step. When the workflows woke up, the replay engine walked the old history, hit the new code branch that did not exist before, and threw NondeterminismError. We rolled the deploy back inside ten minutes, gated the new SMS step behind patched('add-sms-v1'), and re-shipped. Total customer impact: zero, because the orders were still safely paused and resumed cleanly on the second attempt. Total lessons: one, learned permanently.

The numbers after ninety days

We ran the new stack alongside the old one for eight weeks, then in isolation for four. The comparison the operator's CFO asked for looked like this.

• Monthly automation bill: €2,300 to €180
• Number of SaaS dashboards the ops lead opens per week: 4 to 1
• Mean time to detect a silent failure: roughly 6 hours to roughly 90 seconds
• Lines of workflow logic under version control: 0 to all of it
• Engineering time spent on the migration: 7 weeks of one senior, part-time

The €180 figure is honest. It is one CCX13 (4 vCPU, 16GB) plus a CCX23 standby on Hetzner, the Temporal Cloud Essentials namespace, and a Sentry seat. Network egress is rounding error. If they grow another 3x in order volume, the bill goes to about €260. If they had stayed on Zapier through the same 3x, the projection was €6,400.

When Temporal is the wrong answer

Three honest cases where we tell people not to do this.

If your workflows are mostly single-step, Zapier is fine. The whole point of the comparison above is that the operator was running multi-step workflows with retries, branching, and long waits. A "new lead in HubSpot, send a Slack message" automation does not justify any of this.

If your team has no engineer who can debug a stuck workflow, do not migrate. Temporal gives you durable execution and demands competence in return. Workato or Make's enterprise tier is a better fit if you need a no-code interface that someone in marketing can extend.

If you are not on the per-task pricing wall yet, wait. The break-even for this operator was around €800 per month in automation SaaS. Under that, the migration cost more than the savings would pay back inside a year.

A five-minute audit you can run today

Open the last three months of invoices from every automation SaaS you pay. Add them up. Divide by three. If that number is bigger than what you would pay a contractor for two weeks of focused work, you have a sprawl problem worth measuring. Then count how many of those tools your operations lead has logged into this month. If the answer is more than two, the sprawl has already started costing you something the invoice does not show.

When we rebuilt the order pipeline for this Almere operator, the thing we ran into was the assumption that each tool's monthly bill was the real cost. The hidden cost was the Sunday-night phone call. We solved both with a single Temporal worker pool and a week of careful migration. If your stack looks similar and the numbers feel familiar, that is the kind of process automation work we do.