The Make vs n8n Question Is Wrong. Ask This Instead.

By Lazar Milicevic · Published July 3, 2026 · 8 min read

Every Make vs n8n comparison online asks the wrong question. "Which is easier?" is irrelevant once a real client workflow hits ten times its opening volume. The question that actually decides the project: what does this workflow cost, and who owns the infrastructure, when the client stops paying you?

I've shipped production automations on both. Here's the exact matrix I run through before I quote a project — with the operations math, the hosting trade-offs, and the trigger gotchas that only show up after you've deployed.

The no-code vs code framing is a lie both camps sell

Both platforms sell themselves as no-code. Neither is, past week one. Every serious Make scenario ends up with JSON parsing, regex, iterator logic, and error handlers with retry loops. That's code — just code with a worse debugger and no version control. Every serious n8n workflow ends up with a Code node running JavaScript. Also code.

So drop the question "which one lets me avoid programming?" Neither does. The two questions that actually matter:

• What does this workflow look like at 10x current volume?
• Who owns the infrastructure when you and the client part ways?

Those two questions decide the platform. Everything else is preference.

The operations math that flips the decision

Here's a real project. Small business, wanted Gmail triage: inbound customer emails classified, urgent ones pushed to Telegram, the rest rolled into a daily digest. Day-one volume estimate: 120 messages a day. Sounds trivial. Now do the math.

Each message hits:

1. Trigger (Gmail watch)
2. Classifier (LLM call)
3. Router (urgent / normal / spam)
4. Formatter
5. Destination (Telegram or digest queue)

With error handlers and iterator overhead, that's roughly 30 operations per message in Make.com.

120 messages/day × 30 ops = 3,600 ops/day
3,600 × 30 days       = 108,000 ops/month

Make.com's Core plan gives you 10,000 ops. So you're immediately on the Teams tier at $34/month minimum, and you'll blow through that inside a quarter as the client's business grows.

That same workflow on self-hosted n8n on a $6/month VPS has zero marginal cost per operation. The client owns the box. You hand them credentials on day one.

I've watched a client's Make.com bill climb from $29 to $290 in three months. Nothing broke. The workflow just did its job more times.

The break-even table I actually use

Numbers rounded to what Make.com's public tiers looked like at time of writing — verify current pricing on make.com. The shape doesn't change: Make scales linearly with executions, self-hosted n8n scales with your VPS, which is basically flat until you need horizontal workers.

Decision axis one: volume threshold

Under ~1,000 operations per day, Make.com wins on speed to ship. The visual builder is faster for prototyping, the pre-built app connectors are cleaner, and you can hand a client a working demo on a Friday afternoon.

Above ~1,000 ops per day, the math flips hard. Self-hosted n8n dominates because infrastructure cost stays flat while Make's bill scales linearly with every module execution.

The tricky part is that clients underestimate their own volume. The one who told me "about 120 emails a day" was averaging 340 within six months because their marketing started working. If you're quoting on the day-one number, quote in Make. If you're building something the client plans to grow, quote in n8n.

Decision axis two: who owns the infrastructure

This one nobody talks about, and it matters more than the price.

When you build in your Make.com account:

• The client is locked into your account.
• If they fire you, they lose the automation.
• If they want to audit the logic, they need your login.
• If Make changes pricing — and they have, more than once — the client absorbs it with no warning.

When you deploy n8n on the client's own VPS:

• They own the machine and the data.
• Workflows export as JSON. Commit them to the client's Git repo.
• The automation survives your relationship with them.

That's a professional deliverable. The Make version is a rental you're subletting. Some clients don't care — small ops, short engagement, fine. Some clients care a lot — anyone handling customer data, anyone in a regulated vertical, anyone who's been burned by a freelancer disappearing. Ask.

Here's what "client owns it" looks like as a deploy on a $6 Hetzner or DigitalOcean box:

# On the client's VPS, one-time setup
docker run -d --restart=unless-stopped \
  --name n8n \
  -p 5678:5678 \
  -v n8n_data:/home/node/.n8n \
  -e N8N_HOST=automations.clientdomain.com \
  -e WEBHOOK_URL=https://automations.clientdomain.com/ \
  -e GENERIC_TIMEZONE=America/New_York \
  n8nio/n8n

# Put Caddy or nginx in front for TLS, done.
# Workflows live as JSON exports in a Git repo you both have access to.

Total setup time on a fresh VPS: under 30 minutes if you've done it before. The client gets a URL, a login, and a Git repo. If they fire you tomorrow, everything keeps running.

Decision axis three: trigger reliability (where tutorials lie by omission)

Some triggers work well on one platform and poorly on the other. This is where mid-project migrations get born.

• Gmail push via Google Pub/Sub — more stable in n8n because you control the webhook endpoint and the Pub/Sub subscription lives on the client's Google Cloud project. Make's polling behavior can miss messages under burst load.
• Instagram / TikTok / other social APIs — cleaner in Make.com. They maintain those integrations directly and eat the auth churn for you. Building the same in n8n often means HTTP nodes and manually refreshing OAuth tokens.
• Stripe webhooks — identical on both. It's a signed HTTP POST to an endpoint. Toss-up.
• Google Sheets — both fine at low volume. n8n batches better if you're writing thousands of rows.
• Airtable — Make's connector has better field-type handling out of the box. n8n needs more manual mapping.
• Slack / Telegram / Discord — parity. Pick either.

Rule I follow before promising a trigger works

• Search "[connector name] site:community.n8n.io" and "[connector name] site:community.make.com" for the last 90 days.
• If more than two threads report silent field deprecations or auth breakage, budget migration time into the quote.
• I've had to migrate a workflow mid-project because a Make connector silently dropped a field I depended on. Never again — I check the community threads first now.

The actual matrix (what I decide with in five minutes)

Here's the flowchart I run before quoting:

Is projected volume < 1,000 ops/day within 6 months?
├── YES ──► Is the client OK with the automation living in your account?
│           ├── YES ──► Make.com. Ship it Friday.
│           └── NO  ──► n8n on their VPS. Add 2–3 hours to the quote.
│
└── NO  ──► Does the workflow depend on a Make-only connector (IG/TikTok)?
            ├── YES ──► Make on Teams/Pro, warn client about scaling cost.
            └── NO  ──► n8n on their VPS. Non-negotiable above 3k ops/day.

Prototype-only, need to prove concept in an afternoon?
──► Make.com. Migrate to n8n once concept is signed off.

The Gmail triage project I mentioned earlier followed exactly this path. We prototyped in Make in about 40 minutes because we needed to show the client the classification worked before they'd sign off on infra spend. Three weeks later, once monthly ops projected past 100,000 and the client wanted infrastructure on their box, we rebuilt it in n8n.

• Same logic. Different platform.
• Total migration time: 6 hours.
• Client savings over the next 12 months: roughly $3,000 in avoided Make Teams tier upgrades, plus full ownership.

Six hours of migration paid for itself in the first month.

What both camps get wrong

The Twitter debate treats platform choice as identity. It isn't. Nobody on the client's team cares whether you used Make or n8n. They care about three things:

• Does the automation run?
• Do they own it?
• Is the bill predictable?

Pick the tool that answers those three questions for the specific workflow in front of you. If a client's marketing lead is going to grow inbound 5x in a year, Make's linear pricing will bite them. If a client needs a scrappy prototype by Friday to unlock a bigger contract, n8n's setup overhead costs you the deal.

Builders pick per-project. Evangelists pick teams. If you catch yourself in a thread arguing which platform is objectively better, you're not building anything.

Where bizflowai.io fits in this

Most of the workflows we ship at bizflowai.io end up on self-hosted n8n on the client's VPS, precisely for the ownership and cost reasons above — Gmail triage bots, lead intake pipelines, invoice automation, CRM sync. Where a project is short-horizon or leans on a connector Make maintains better (some social APIs, certain marketing platforms), we start there and migrate once the workflow proves itself. The decision is always downstream of the client's volume trajectory and whether they need the automation to survive us walking away. That's the framing we bring to every scoping call.

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.