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

A developer compared Make.com and n8n by building the same nine-step AI lead-routing agent in both tools. They found that Make is better for simple workflows under 1,000 operations per month, but n8n wins for non-trivial automation due to its native custom code support, retry logic, and lower cost at scale. The developer saved $564 annually on a single client workflow by switching from Make Pro to self-hosted n8n.

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: js // 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: | 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. 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: 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 https://bizflowai.io for our services, case studies, and AI consulting.