When Make.com hits its limits

Make.com is excellent until it isn't

We like Make. The visual debugger is better than n8n's, the operations model is honest, and the routers handle branching that Zapier struggles with.

But every tool has a ceiling. Here is where Make hits its.

Operations cost compound fast

Make charges per operation. A scenario with a router, three branches, and an HTTP module easily uses 5–10 operations per run. Multiply by 10k runs a month and you are paying real SaaS money.

Custom backends do the same work for the cost of a small VPS.

Error handling is per-module, not per-scenario

You cannot say "retry the whole scenario from step 1 if anything fails." You set error handlers on each module. For 3-step scenarios that is fine. For 12-step scenarios it becomes a maintenance nightmare.

A FastAPI + Celery service gives you scenario-level transactions for free.

Data stores are slow and limited

Make's data stores are convenient for tiny state. They are not Postgres. Queries are limited, joins are impossible, and the latency is noticeable at scale.

If your scenario reads or writes structured data on every run, you already need a real database.

Scheduled scenarios drift

A scenario "every 15 minutes" actually runs every 15 minutes plus whatever queue depth Make has. Under load, scheduled jobs can drift by hours. We have seen end-of-day reconciliations that ran the next morning.

A custom backend with a real scheduler (Celery beat, APScheduler, cron) does not drift.

What we tell clients

If Make is costing more than 200 USD per month and you have a single critical scenario that everyone in the business depends on, it is time to move that one scenario to a custom backend.

Keep Make for the rest. Do not migrate everything just because one workflow grew up.