Make.com Will Bankrupt You at 10K Ops — Here's the Math

Abstract tech illustration: Make.com Will Bankrupt You at 10K Ops — Here's the Math

Make.com sent me a $99 invoice last month for one lead-gen workflow. The exact same workflow, rebuilt on self-hosted n8n, costs me about $6 in electricity. Same triggers, same logic, same CRM output — and most solopreneurs don't see the bill coming until invoice number two.

This is the math nobody screenshots in the "no-code is the future" videos. I run both stacks for paying clients right now, so I'll show you the real numbers, the exact crossover point, and the playbook I give clients when their workflow outgrows the managed tier.

What an "operation" actually costs on Make.com

A Make.com operation is one module execution — not one workflow run. A single lead passing through a 15-module scenario burns 15 operations. Make Core is $9/mo for 10K ops, Pro is $16, Teams is $29. Sounds cheap until you do the multiplication.

Here's the lead-gen workflow I run for a client. Standard small-business stack: webhook in, enrichment, scoring, CRM sync, outbound sequencing.

Webhook trigger              → 1 op
Clearbit enrichment (HTTP)   → 1 op
Router (3 branches)          → 1 op (per active path)
Score calculation            → 1 op
Iterator (tags array, ~4)    → 4 ops
HubSpot upsert               → 1 op
Slack notify                 → 1 op
Conditional follow-up email  → 1 op
Aggregator                   → 1 op
Error handler retry path     → 1-3 ops
─────────────────────────────────────
Per lead: ~14-17 operations

At 2,500 leads/month, that's ~40,000 ops. Pro tier maxes at 10K, so you're on the 40K Pro plan at roughly $99/month — $1,188/year for one workflow. Add retries on flaky third-party APIs and you'll see months hit $120+.

The hidden multiplier is branching. Every router path, every iterator pass, every aggregator counts. Add a single 5-item iterator inside an existing scenario and you've just 5x'd that section's op count without 5x'ing your output.

What gets billed that beginners miss

  • Each iterator pass (not the iterator itself)
  • Each router branch that fires (not the router)
  • Webhook fan-out responses
  • Retries on HTTP error codes
  • Aggregator collection steps

What n8n self-hosted actually costs

n8n self-hosted has no per-operation meter. You pay for the box. That's the entire pricing model.

My setup runs on a low-power mini PC in the home office. Pulls roughly 12W under typical load. At $0.16/kWh (rough US average), that's about $1.40/month in electricity for the n8n container itself. Round up to $4-6/mo accounting for the rest of the box and you're done.

If you don't want hardware in the house, a $5/mo Hetzner CPX11 or a $6 DigitalOcean droplet runs it fine for workflows under ~100K ops/month. Docker compose, one file:

services:
  n8n:
    image: n8nio/n8n:latest
    restart: always
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=automation.yourdomain.com
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://automation.yourdomain.com/
      - GENERIC_TIMEZONE=America/New_York
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
    volumes:
      - ./n8n_data:/home/node/.n8n
  postgres:
    image: postgres:16
    restart: always
    environment:
      - POSTGRES_USER=n8n
      - POSTGRES_PASSWORD=changeme
    volumes:
      - ./pg_data:/var/lib/postgresql/data

That's the stack. Caddy or Cloudflare Tunnel in front for HTTPS, automated nightly Postgres dumps to S3-compatible storage, done. Setup time on a clean VPS: ~45 minutes if you've done it before, half a day if you haven't.

Run the same 40K-ops workflow on this box and the cost line doesn't move. Run 400K ops on it and the cost line still doesn't move — you'll bottleneck on CPU and API rate limits long before you bottleneck on price.

The crossover point: ~8,000 operations per month

After running both stacks in parallel for months across multiple client workflows, the break-even sits around 8,000 ops/month. Below that, Make wins on total cost of ownership. Above it, n8n wins on dollars, and the gap widens fast.

Monthly ops Make.com n8n self-hosted Difference
1,000 $9 (Core) ~$6 +$3
5,000 $9 (Core) ~$6 +$3
10,000 $16 (Pro) ~$6 +$10
20,000 ~$34 (Pro 20K) ~$6 +$28
40,000 ~$99 (Pro 40K) ~$6 +$93
100,000 ~$200+ ~$10 (bigger VPS) +$190
400,000 ~$700+ ~$20 (CPX21) +$680

The reason 8K is the right line and not 5K or 15K: under 8K ops, the time you'd spend self-hosting — Docker, reverse proxy, SSL renewal, backup scripts, monitoring, your own error-queue logic — is worth more than the $9-16 subscription delta. Your hourly rate beats the savings. Past 8K, both the dollar gap and your operational confidence in the workflow are high enough that the migration pays for itself in the first month.

The migration playbook (1-2 days for moderate workflows)

The mental model maps almost 1:1. Make's "modules" are n8n's "nodes." Routers become IF/Switch nodes. Iterators become Split In Batches. Aggregators become Merge or Code nodes. Data mapping syntax is similar — {{$json.fieldName}} in n8n vs Make's drag-from-bundle.

Here's the order I migrate in:

  1. Export the Make scenario as a blueprint (JSON). Use it as reference, not an importer — there's no clean auto-converter that's worth trusting.
  2. Rebuild trigger first. If it's a webhook, point a test source at the new n8n webhook URL and confirm payload shape matches.
  3. Port one branch end-to-end before doing the rest. Get one lead all the way through to the CRM. This catches 80% of the gotchas (auth, header differences, response parsing).
  4. Port remaining branches. Reuse credentials via n8n's credential store.
  5. Wire error workflows. n8n's Error Trigger node + a Slack/email alert is what replaces Make's built-in error notifications.
  6. Run both in parallel for 7 days. Feed Make the live traffic, mirror to n8n via a fork at the webhook. Diff the outputs.
  7. Cut over. Update the source webhook URL. Leave the Make scenario paused (not deleted) for two weeks as a rollback.

Most moderate workflows — 10-25 modules — take one focused day to rebuild and one day to validate. Workflows with weird custom Make functions or heavy aggregator logic can take three.

What you'll have to build yourself

  • Backups (cron + pg_dump + rclone to B2 or S3, ~30 lines of bash)
  • Uptime monitoring (UptimeRobot free tier on your webhook URL works)
  • Update process (docker compose pull && docker compose up -d monthly)
  • SSL renewal (Caddy or Cloudflare Tunnel handle this automatically)

When you should NOT migrate

I want to be honest here because the dollar math makes n8n look obvious. It isn't always.

Stay on Make.com if:

  • The workflow runs under 8K ops/month and is stable. Don't optimize a $16 bill.
  • You're still validating the idea. Managed platforms beat self-hosted for speed of iteration when you don't yet know if the workflow is right.
  • You don't want to be responsible for uptime. If a Postgres container falls over at 2am, that's now your problem, not Make's SRE team's problem.
  • The client is non-technical and might want to edit the workflow themselves later. Make's UI is more forgiving for that.
  • You're billing the client for ops as a pass-through. Some agencies do this and the markup covers the cost.

Migrate to n8n if:

  • Sustained 8K+ ops/month for two consecutive months.
  • Data sovereignty matters — healthcare-adjacent, legal, financial records, anything where "where does this data live" is a real question from your client.
  • The workflow has heavy branching/iterators that multiply ops disproportionately.
  • You're running 5+ workflows for the same client and could consolidate them onto one n8n instance.

The framing isn't "Make bad, n8n good." It's: pick the platform that matches the stage of the workflow.

Why bizflowai.io helps with this

For most clients I work with through bizflowai.io, the pattern is exactly what's described above: validate fast on a managed stack, then move the proven workflows to self-hosted infrastructure once the volume justifies it. The work is rarely "build one automation" — it's auditing which existing workflows are bleeding money on per-op pricing, rebuilding the high-volume ones on n8n with proper error handling and backups, and leaving the low-volume experiments where they are. That's the version of automation that actually compounds instead of quietly eating your margin.


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.