Make.com vs n8n: I Built the Same AI Agent in Both

A client needed a lead-routing agent. Gmail in, AI classifies by industry and urgency, hot leads to a sales rep on Telegram, cold ones to the CRM with a tagged follow-up. Nine steps. I built it three times — Make, n8n, then raw code — because I picked wrong the first two times. Here is the decision rule I wish someone had given me.

The exact workflow I rebuilt three times

Before I argue about tooling, here is the spec, because vague comparisons are useless. Nine nodes total: Gmail trigger → extract sender + body → OpenAI classification (industry, urgency 1-5) → branch on urgency → Telegram message to sales rep (hot) → CRM upsert with tag (cold) → follow-up sequence enqueue → log to Postgres → error catch.

That is the surface. What killed me was the second-order work:

• Retry logic when OpenAI returns a 429 or the CRM webhook 502s
• A custom HTTP call to an invoicing API with a non-standard signed auth header
• Volume: roughly 40,000 executions/month once you count retries and polling

Every comparison post online benchmarks the happy path. Real client work is the unhappy path. That is where Make and n8n diverge hard.

Where Make actually beats n8n (I will say it out loud)

For a workflow with under ten steps, no retry logic, no custom auth, and under 1,000 ops/month, Make is the better choice. The UX is genuinely cleaner and you will ship faster. I built the happy-path version of this agent in Make in eight minutes flat.

Specifically:

• The Gmail trigger authenticated in two clicks. n8n's OAuth flow took me about four minutes the first time because you have to register a Google Cloud project.
• The OpenAI module has a model dropdown and a structured-output toggle. No JSON wrangling.
• The left-to-right scenario canvas reads like a sentence. When I screen-share with non-technical clients, they understand a Make scenario without me explaining.
• Built-in modules for Telegram, HubSpot, Pipedrive, Notion — all pre-authed with sensible defaults.

If your automation looks like "trigger → enrich → send" and runs a few hundred times a month, stop reading and use Make. Your time is worth more than the $9–29/month subscription. Most YouTubers who tell you "always use n8n" are selling a self-hosting course.

Where Make falls off a cliff: retries, custom auth, and ops pricing

Make's pricing model is per-operation, and every error handler, every router branch, every iteration consumes ops. The moment you add real production logic — retries, dead-letter queues, idempotency checks — the ops counter accelerates faster than your feature set.

Here is what happened on this specific client:

1. The client asked for retry logic. If the OpenAI call fails or the CRM is down, the lead can't vanish.
2. Make's native retry is limited to a few attempts on a small subset of modules. For OpenAI failures, I had to build error handlers that route to a data store.
3. Each error handler branch costs operations against the monthly quota.
4. To replay failed runs, I built a separate scenario that polls the data store every five minutes. That scenario alone burned ~8,600 ops/month doing nothing useful.

At around 1,200 real-traffic ops/month plus the polling overhead, the workflow needed the Pro tier. Make's UX is great until you're paying for the privilege of working around its limitations.

Then came the invoicing API. Non-standard auth header, HMAC-signed payload. In Make, the HTTP module on the lower tiers cannot generate the signature inline — you'd need a separate scenario, a webhook, and a data store hop. Ugly. In n8n:

// n8n Function node — 6 lines
const crypto = require('crypto');
const ts = Date.now().toString();
const payload = JSON.stringify($json.body);
const sig = crypto.createHmac('sha256', $env.API_SECRET)
                  .update(ts + payload).digest('hex');
return [{ json: { ...$json, headers: { 'X-Signature': sig, 'X-Timestamp': ts } } }];

Done. That single capability — drop into JavaScript or Python when the visual nodes can't express what you need — is the deciding factor for any non-trivial workflow.

The cost math nobody puts in a comparison post

This is where solopreneurs actually feel the choice. Real numbers from this client, audited from billing dashboards:

Metric	Make.com (Pro)	n8n self-hosted	n8n Cloud (Pro)
Executions/month (with retries + polling)	~40,000 ops	~40,000	~40,000
Monthly cost	$47	$0 marginal*	$50
Annual cost	$564	~$0	$600
Custom code support	Paid tier, limited	Native (JS + Python)	Native
Native retry/error workflows	Limited	Yes	Yes
Self-host option	No	Yes	No

*Marginal cost. My home server (mini PC, 32GB RAM, Ubuntu under WSL on one box, bare-metal Debian on another) runs eight other things. Amortized hardware is roughly $4/month of electricity.

Over a year, that's $564 saved on one client workflow. Run five client workflows and you've paid for a developer-grade server. Run ten and you've funded a year of API credits.

The Make pricing trap is not the headline number. It's that every architectural improvement you make — better error handling, idempotency, observability — costs you ops. n8n charges you once for the engine, then your improvements are free.

Self-hosting n8n in 12 minutes (the actual setup)

If you're going the n8n route, here is the Docker Compose I use on the client server. Postgres for persistence, n8n behind a Caddy reverse proxy for TLS, encrypted credentials at rest.

# docker-compose.yml
services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: n8n
    volumes:
      - ./pgdata:/var/lib/postgresql/data

  n8n:
    image: n8nio/n8n:latest
    restart: unless-stopped
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: ${DB_PASSWORD}
      N8N_ENCRYPTION_KEY: ${ENCRYPTION_KEY}
      N8N_HOST: automation.yourdomain.com
      WEBHOOK_URL: https://automation.yourdomain.com/
      N8N_PROTOCOL: https
      EXECUTIONS_DATA_PRUNE: "true"
      EXECUTIONS_DATA_MAX_AGE: 168  # 7 days
    ports:
      - "127.0.0.1:5678:5678"
    depends_on:
      - postgres
    volumes:
      - ./n8n-data:/home/node/.n8n

# .env
DB_PASSWORD=$(openssl rand -hex 24)
ENCRYPTION_KEY=$(openssl rand -hex 32)

docker compose up -d

A few things I learned the hard way running this in production:

• Always set EXECUTIONS_DATA_PRUNE. Without it, the Postgres db grew 400MB/week on this client's workload. After a year the n8n UI crawled.
• Use the queue execution mode (EXECUTIONS_MODE=queue with Redis) once you're past 10k executions/day. Single-process mode will block on a slow webhook.
• Back up n8n-data and the Postgres dump nightly. Credentials are AES-encrypted with N8N_ENCRYPTION_KEY — lose that key, lose every saved credential.
• Put it behind Cloudflare Tunnel or Tailscale, not a raw exposed port. n8n's UI authentication is fine but webhooks are public by design.

Twelve minutes from docker compose up to a working webhook in production, if your DNS and TLS are already set up.

The decision rule I give every client

Skip the holy war. Here is the actual rule:

• Fewer than 10 steps, no retries, no custom auth, under 1,000 ops/month → Make. Ship in an hour. Worth the $9–29.
• Branching, retries, custom APIs, or any real volume → n8n from day one. Self-hosted if you have a server, cloud if you don't.
• Workflow needs version control, code review, CI/CD, or multi-environment deploys → skip both. Write it in Python with a task queue. The visual tools become friction.

The trap is building in Make first and migrating later. I have done that rebuild three times. It is always two full days I don't get back, because Make's data shapes don't map cleanly to n8n's, and your error handlers are scenario-specific.

The Make-vs-n8n debate is the wrong question. The right question: does my workflow need logic Make can't express cleanly? If yes, n8n today. If no, Make today. Pick once, build once.

Quick gut check before you start building

• Will I ever call an API with a custom signed header? → n8n
• Do I need to retry failed runs without burning ops? → n8n
• Will I run more than 5,000 executions a month? → n8n
• Is the workflow under 10 steps and will stay there? → Make
• Will a non-technical client need to read the canvas? → Make

Why bizflowai.io helps with this

For client workflows we run through bizflowai.io, we default to n8n self-hosted on a managed server because the retry/custom-auth/volume math almost always wins for lead-routing, invoicing, and CRM-sync automations. We still build in Make when the workflow is genuinely simple and the client wants to own the canvas themselves. The honest part of the job is telling the client which tool fits before the build, not after — that one conversation saves the two-day rebuild every time.

---

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.