Replacing 50 Zaps with one FastAPI service

The starting point

The client had 47 active Zaps. Together they handled order ingestion, customer support routing, inventory updates, and three different report emails. The Zapier bill was 1,200 USD per month. The Slack channel for "Zap failed" notifications had 300+ messages per week.

The team had stopped trusting it. People were copy-pasting data manually because they assumed something was broken.

What we found

Across 47 Zaps, there were 6 actual business processes:

1. Order received → validate → enrich → push to fulfillment + accounting
2. Support email → categorize → route → notify on-call
3. Inventory low → reorder → notify warehouse
4. Daily sales report → format → email
5. Weekly cohort report → format → email
6. Refund issued → update accounting → notify customer

Each process had grown into 5–10 Zaps as edge cases were added. Each Zap was edited by a different person at a different time. There were three contradictory implementations of "valid order."

The replacement

We built a single FastAPI service with six top-level endpoints, one per business process. Each endpoint:

• Accepted the source webhook (Shopify, email parser, Slack)
• Validated input with Pydantic
• Enqueued work to Celery
• Returned 200 in under 100ms

Total backend code: about 1,800 lines of Python.

The migration plan

Three months, in waves:

• Month 1: build the FastAPI service in parallel. Route a 5% sample of traffic to it. Compare outputs.
• Month 2: ramp to 50%, then 100%, one process at a time. Keep the Zaps as a hot standby.
• Month 3: delete the Zaps. Cancel the Zapier subscription.

We did not delete anything until we had 30 consecutive days of green metrics.

The results

• Zapier bill: 1,200 USD → 0
• Hosting bill (Postgres + Redis + small VPS): 80 USD
• Failed runs per week: 300+ → about 4
• Time-to-debug a failure: 30+ minutes → under 5 minutes

The "Zap failed" Slack channel became "errors" and now mostly contains real downstream issues (a partner API was down, a malformed CSV arrived), not phantom failures.

What we would do differently

We over-engineered the first process. The team was used to seeing every step in Zapier's UI, and we built a status page that showed each stage. Most of it went unused. For the next five processes we cut the status page down to "received / processing / done / failed" and called it a day.

Boring works.