The 15-Module Ceiling: Where Make.com Quietly Breaks

By Lazar Milicevic · Published June 30, 2026 · 8 min read

A client called me at midnight last month. His Make.com scenario had been silently dropping 23% of inbound leads for four days. Router at the top, three nested iterators, an aggregator trying to stitch the results, error handler bolted onto module fourteen. It worked for two weeks. Then Gmail rate-limited one branch, the iterator inside the router didn't propagate the error, and the aggregator quietly ate the rest.

This is the pattern I see every week. Make.com is genuinely the easiest tool on the market — for the first ten modules. Past fifteen, it's the hardest thing you'll ever maintain. Here's exactly where the wall sits, what disappears on the way up, and the real monthly bill at 4,000 ops a day.

The exact point where Make.com turns hostile

The ceiling is module fifteen, not thirty, not fifty. Past fifteen modules with any combination of routers, iterators, and aggregators, debugging time grows non-linearly and silent failures become the default mode. This isn't a marketing number — it's the threshold where Make's execution model (per-module state, route-based errors, no real code) stops matching how production flows actually fail.

The growth pattern I see in every client onboarding looks identical:

Nothing dramatic happens at fifteen. There's no popup, no warning. The scenario just gets quietly impossible to reason about. Collapsed routes hide error handlers. Iterators inside routers don't propagate exceptions the way you'd expect. The aggregator finishes with a partial result and reports success.

That's the trap: Make doesn't fail loud. It fails silent and looks healthy on the run history page.

The four things you lose past module ten

Every solo founder I've audited hits the same four walls in roughly the same order. None of them are obvious until you're trying to fix a production flow at 11 PM.

1. Real code nodes. Make gives you formula functions and a JSON parser. The moment you need actual logic — exponential-backoff retry, a deduplication hash across three data sources, a polymorphic parser for four invoice formats — you chain filter modules and set-variable steps. Eight lines of JavaScript becomes a six-module pyramid. Every module is a billable operation and a potential failure point.

What this looks like in n8n:

// One code node. One operation. One thing to debug.
const seen = new Set();
const deduped = [];
for (const item of $input.all()) {
  const hash = `${item.json.email}|${item.json.invoice_id}`;
  if (!seen.has(hash)) {
    seen.add(hash);
    deduped.push(item);
  }
}
return deduped;

In Make, the same dedup logic is roughly: Iterator → Set variable (hash) → Array aggregator → Filter (unique) → Iterator again. Five modules, five operations per item, and a debug session that requires clicking through each execution one at a time.

2. Proper try-catch. Make's error handlers are route-based, not block-based. You cannot wrap three modules in a single try, catch one exception, and continue. You attach a separate error route to every module that might fail. A 15-module scenario commonly needs 8 error routes. They're invisible when collapsed, they fire in unpredictable orders, they don't share state. In n8n you put one error trigger on the workflow, catch everything in one node, log it, move on.

3. Version control. Make's blueprint export is JSON that isn't diff-friendly. You cannot review a pull request on a Make scenario. You cannot see who changed what. Two people edit the same scenario, last save wins, the other person's work is gone. n8n workflow JSON in a Git repo gives you actual history, code review, and rollback. For a solo flow it doesn't matter. The moment a contractor or VA touches it, it matters a lot.

4. Sub-workflow reuse. In n8n you call one workflow from another, pass data in, get a response back. Build a Gmail-fetch sub-workflow once, reuse it in twelve scenarios. In Make there's no real equivalent — you copy-paste the modules. When Google deprecates a scope (they did this last year), you update twelve scenarios instead of one. I watched a client burn six hours on exactly that migration.

The maintainability tax in plain numbers

• Bug location time: Make ~6 hours (click through every module's history). n8n ~30 minutes (logs + console.log in code node + full data tree at every step).
• Adding a new branch: Make ~45 min (re-wire router, add error route, test). n8n ~15 min (duplicate node, edit, commit).
• Onboarding a contractor: Make = screen-share session. n8n = "here's the repo."

The real bill at 4,000 ops/day

This is the part the 60-second YouTube shorts skip. Here are the actual numbers from a Gmail triage + CRM routing flow I help clients run.

• Daily volume: ~4,200 operations
• Monthly volume: ~126,000 operations
• Make.com mid-tier plan: $29 base, plus overage. Once you exceed the included ops bucket and add a couple of higher-tier modules, you land around $180/month.
• Self-hosted n8n on a $5 VPS: $5 server + ~$2 backups = $7/month.

That's a 96% cost reduction for identical logic. Same Gmail input, same Notion writes, same Slack alerts, same AI classifier.

# Self-hosted n8n in two commands on any $5 VPS
docker volume create n8n_data
docker run -d --restart unless-stopped \
  --name n8n -p 5678:5678 \
  -v n8n_data:/home/node/.n8n \
  -e N8N_HOST=automation.yourdomain.com \
  -e WEBHOOK_URL=https://automation.yourdomain.com/ \
  n8nio/n8n

Add Caddy or nginx in front for HTTPS, point a subdomain at it, you're done. The first time I set this up it took about 25 minutes. After that, every new client deployment is under 10.

The Make pricing model has a deeper problem than the headline number: every module is a billable operation. The six-module pyramid I described above? That's 6× the ops vs. one code node doing the same work. As your flow grows, your bill grows quadratically — more modules, executed more times, each one billed.

Build time vs. total cost of ownership

The Make pitch is faster onboarding. It's partially true. I clocked the same Gmail-Notion-Slack flow at:

• Make.com first build: 40 minutes
• n8n first build: 55 minutes

A 15-minute difference. Not a paradigm shift. But that's the wrong number to optimize for, because flows don't get built once — they get debugged repeatedly.

Total cost of ownership flips hard the first time something breaks. And something always breaks — APIs change scopes, rate limits tighten, a vendor adds a required field. The honest comparison isn't "which is faster to ship on day one." It's "which is cheaper to own on day 200."

The rule I give every client

Here's the decision tree I actually use, no hedge:

Build in Make if all of these are true:

• Under 10 modules
• Single-tenant (only you use it)
• No money flows through it (no invoicing, no payments, no payroll)
• You'll never hand it to a developer

The visual editor is genuinely friendlier, onboarding is smoother, and the operational overhead is zero. For a personal Gmail-to-Notes flow, Make is the right choice. I'm not anti-Make for the use case it was designed for.

Start in n8n if any of these are true:

• Over 10 modules, or you can see it getting there
• Multi-tenant or customer-facing
• Touches money (invoices, payments, contracts, payroll)
• Will need code review or rollback
• A contractor will edit it

Do not migrate later. I've done three Make→n8n migrations in the last six months and every one took longer than rebuilding from scratch. The flows look superficially similar but the error model, the data shape between modules, and the iterator semantics don't translate cleanly. Budget dies in migration.

The meta-point is this: no-code tools have a complexity ceiling, and Make's is lower than the marketing suggests. Pick the tool that matches where the flow will be in six months, not where it is on day one.

Where bizflowai.io fits in

For clients who hit the 15-module wall, we usually rebuild the critical flows on a self-hosted n8n instance — versioned in Git, with the messy logic moved into proper code nodes and the AI classification handled by routed models (cheap one for triage, smarter one only when the cheap one is unsure). The Gmail-triage + CRM-routing pattern from this post is one of the standard automations bizflowai.io ships for small teams; the goal is always a stack the client can actually maintain after we hand it back, not another tool they have to call us about at midnight.

Related reading

• Make.com Will Bankrupt You at 10K Ops — Here's the Math — the full cost curve, with overage tiers.
• Make.com vs n8n: I Built the Same AI Agent in Both — head-to-head build, every module counted.
• bizflowai.io vs Make.com (2026): Honest Breakdown — where each tool actually wins.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.