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.

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:

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

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:

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.

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:

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.

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

*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.

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.

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
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:

EXECUTIONS_DATA_PRUNE

.EXECUTIONS_MODE=queue

with Redis) once you're past 10k executions/day. Single-process mode will block on a slow webhook.n8n-data

and the Postgres dump nightly.N8N_ENCRYPTION_KEY

— lose that key, lose every saved credential.Twelve minutes from docker compose up

to a working webhook in production, if your DNS and TLS are already set up.

Skip the holy war. Here is the actual rule:

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.

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.

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.