AX/G/003

Zapier / Make.com vs custom automation: when to migrate

No-code platforms are great for starting. When they start to hurt — and what to actually rewrite on your own stack.

Most common first-call question: "we use Zapier, is it worth switching to something custom?" Standard answer: most likely not yet. A no-code platform at $50/month covers 70% of small business needs, and that is fine. But there are concrete signals when it starts to hurt.

Most companies that migrate too early lose money on it. Migrating too late also costs. These 7 signals show the moment.

What Zapier / Make.com do well

To be clear — no-code platforms are excellent for many scenarios:

  • SaaS ↔ SaaS integrations — Slack ↔ Notion, Stripe ↔ Google Sheets, Calendly ↔ HubSpot. Setup in 15 minutes.
  • Simple workflow automations — "when someone fills the form, add to CRM and notify Slack".
  • Trigger-action pattern — one event triggers a series of actions.
  • Low scale — a few hundred operations per month, where a 5-second delay does not hurt.
  • No compliance requirements — where audit trail and SLA are not critical.

For these uses, a €3000+ custom build is overkill. You pay $50/month, it works, done.

Signal 1: Cost crossed €300/month

Zapier scales linearly with operations. Pro plan at $29.99/month covers 2000 tasks. Thousands of operations = hundreds of dollars per month. Make.com the same. A custom pipeline on your own VPS (€30-80/month hosting) has no such scaling cost — operation #10,000 costs the same as operation #100.

Threshold: if you pay >€300/month for a no-code platform, a custom build at €3-6k setup + €200/month retainer pays back in ~1.5-2 years. Plus it scales further with no added cost.

Signal 2: Browser automation, not API integration

Zapier / Make.com are great when the source has an API. They are useless when you must scrape a site without an API — most competitors, gov portals, tender portals, listings, shops without a merchant API. Workaround via "Webhook + external scraping service" works but is brittle and expensive.

A custom build with Playwright/Puppeteer handles this natively. Threshold: if >30% of your workflows need scraping without an API, time for custom.

Signal 3: Anti-bot on the target

On more important targets (Nike, premium shops, some social platforms, gov portals) Zapier hits Cloudflare / Akamai / Datadome and breaks. You can route through proxy + headless browser but Zapier has no native support — workaround via third-party scrape APIs ($100-500/month extra).

Custom build with residential proxy pool + fingerprint rotation solves this directly. Threshold: if several key targets break on anti-bot, your no-code stack no longer fits.

Signal 4: Became a "mystery artifact" in the company

Observed pattern: founder built 40 Zaps over 3 years, each named "untitled_zap_47", no one knows what each does. Something breaks, debugging takes 2h navigating the platform. After 6 months an engineer leaves and shouts "we have to rewrite all of this".

Custom build in a monorepo, with code review, schema validation, tests — debug takes 15 min instead of 2h. Threshold: if you have >20 Zaps that cannot be audited or tested, custom brings order.

Signal 5: Compliance / audit trail required

Zapier logs "task ran successfully" but not the payload, not versioned. Make.com is better but still a black box for an auditor. Regulated industries (fintech, KYC, healthcare, real estate processing) require audit trail with timestamps, sources, immutable logs. No-code cannot do this legally.

Custom build with OpenTelemetry, immutable event log, S3 archive — natively. Threshold: if a client asks about audit trail or you are in a regulated industry, no-code is not enough.

Signal 6: Business criticality

Zapier has incidents. Make.com has incidents. In 2024 both had several hours of downtime per quarter. If automation drives your revenue (price intelligence, lead gen, opportunity alerts) — a few hours of downtime is real business cost. Plus you do not control failover, retry policy, dead-letter handling.

Custom build on your own infrastructure: you control SLA, redundancy, recovery. Threshold: if a pipeline is critical-path for revenue, no-code is too much third-party risk.

Signal 7: Compound complexity

Zapier scenarios with 12 steps, conditional logic, branching, error handling become unreadable. Remember the conditions you set 6 months ago? Neither does your colleague. Make.com is better at this (visual programming) but for complexity >15 steps + branching it gets brittle.

Code (TypeScript) with tests, type safety, modular functions — natural expression of complex logic. Threshold: if your core workflow has >10 steps with branching, no-code starts to struggle.

Migration strategy (if you decide)

Do not migrate everything at once. The working pattern:

  1. Phase 1: leave stable, low-cost workflows in Zapier (e.g. CRM ↔ Slack alerts).
  2. Phase 2: identify 1-3 workflows that hurt the most (cost, anti-bot, audit, criticality). Migrate those first.
  3. Phase 3: keep a hybrid. Custom does heavy lifting, Zapier still does simple SaaS↔SaaS integrations.

Most of our clients have a hybrid stack: 8-15 Zaps for simple things + custom Python/TypeScript pipeline for scraping/decision/AI. Usually a cost optimum.

The point

Migrating from Zapier/Make to custom is not binary. Most small businesses should not migrate fully — keep no-code for 70% of workflows, add custom for the 30% where no-code hurts. Economic threshold: ~€300/month no-code cost + sharp technical limits (anti-bot, browser automation, audit, criticality). Below that — stay on Zapier, custom will not pay back.

Hitting a similar problem?

Most of these techniques we ship to production.

If this article resonates with something you are trying to solve — write. Initial project assessment is free.