n8n vs Make: My Decision Tree for Client Automations

Early version. I'll deepen this with concrete client numbers as I publish more automations.

Most of my freelance automation work goes through n8n. A smaller slice goes through Make.com (formerly Integromat). A third — quietly larger than people think — goes through plain TypeScript on Cloudflare Workers or a tiny Node script. Here's how I decide.

The default: n8n, self-hosted

For Turkish SMB clients, n8n self-hosted on a $6 VPS is my default. Three reasons.

Data residency. A real KVKK conversation comes up the moment a workflow touches customer records — invoices, lead lists, anything with a name and a phone number. Hosted Make.com runs in the EU; that's fine for many cases, but a Turkish KOBİ patron understands "kendi sunucumuzda" faster than "EU sunucusunda işleniyor, sözleşme uygun." Self-hosted n8n closes that conversation in 30 seconds.

Cost shape. Make charges per operation. A workflow that fires 50,000 times a month — common for daily CSV sync, Trendyol order pull, fatura matching — hits Make's "Teams" tier ($29/mo) and keeps climbing. The same workflow on n8n self-hosted is one VPS bill flat. I price client engagements assuming linear data growth and Make's tier ramps make me nervous.

Custom code blocks. n8n's Function node is full JavaScript. I write small adapters all the time — parseTcKimlik, normalizeTurkishPhone, mapTrendyolStatus. Make has functions too but the IIFE syntax and limited package access mean I end up shelling out to a Cloudflare Worker for anything non-trivial. With n8n the adapter stays in the workflow.

When I pick Make

One-off marketing automations where the client is non-technical and wants to inspect the workflow themselves. Make's visual editor is genuinely better than n8n's — drag, drop, see. For a workflow the client will open once a quarter, Make wins on operability.

Integrations n8n doesn't have natively. Make has a wider connector catalog. If the client needs a niche Turkish accounting tool (Logo, Mikro, Paraşüt) and Make has it but n8n doesn't, I won't reinvent the wheel for a 3-step workflow.

Trial work. First engagement, unclear scope, client is paying hourly. Make's "build it in an afternoon" speed lets me prove value before committing to infrastructure.

When I reach for code instead

The honest answer is: more often than you'd think.

If a workflow has any of these properties, I drop the visual builder and write code:

More than 3 conditional branches. Visual editors turn into rats' nests at branch 4.
Database transactions. Both n8n and Make can call Postgres, but neither does multi-statement transactions cleanly. If I need atomic writes, it goes to a Worker.
Heavy LLM use. n8n has OpenAI/Anthropic nodes, but for any non-trivial prompt chain I want type-safe parsing (Zod), streaming, retries with backoff, and prompt versioning. That belongs in code.
Anything that touches Asansoft. The B2B SaaS has its own n8n-adjacent automation layer driven from Supabase Edge Functions. Workflow drift between systems isn't worth it.

The real cost is not the bill

The dollar cost difference between Make at $29/mo and n8n self-host at $6/mo is trivial for a working client. The real cost is the cost of changing your mind. Visual workflows are hard to refactor. They're hard to diff in git. They're hard to test. They're great until they aren't, and the "aren't" arrives faster than anyone expects.

So I'm conservative now. n8n for the long-haul ops automations. Make for the one-offs. Code the moment the workflow starts having opinions about its own output.

A simple rule of thumb

If the client needs…	I pick
Daily ops automation, KVKK-sensitive data, > 6 months horizon	n8n self-host
Marketing/CRM workflow, non-technical owner, < 50k ops/mo	Make.com
Stateful logic, LLM chain, atomic writes	Plain TypeScript + Cloudflare Worker

That's the decision tree. It'll change. Drop a line if your experience is different.

Get in touch if you want help making the call for a specific workflow.

Early version. I'll deepen this with concrete client numbers as I publish more automations.

The default: n8n, self-hosted

For Turkish SMB clients, n8n self-hosted on a $6 VPS is my default. Three reasons.

When I pick Make

Trial work. First engagement, unclear scope, client is paying hourly. Make's "build it in an afternoon" speed lets me prove value before committing to infrastructure.

When I reach for code instead

The honest answer is: more often than you'd think.

If a workflow has any of these properties, I drop the visual builder and write code:

More than 3 conditional branches. Visual editors turn into rats' nests at branch 4.
Database transactions. Both n8n and Make can call Postgres, but neither does multi-statement transactions cleanly. If I need atomic writes, it goes to a Worker.
Heavy LLM use. n8n has OpenAI/Anthropic nodes, but for any non-trivial prompt chain I want type-safe parsing (Zod), streaming, retries with backoff, and prompt versioning. That belongs in code.
Anything that touches Asansoft. The B2B SaaS has its own n8n-adjacent automation layer driven from Supabase Edge Functions. Workflow drift between systems isn't worth it.

The real cost is not the bill

So I'm conservative now. n8n for the long-haul ops automations. Make for the one-offs. Code the moment the workflow starts having opinions about its own output.

A simple rule of thumb

If the client needs…	I pick
Daily ops automation, KVKK-sensitive data, > 6 months horizon	n8n self-host
Marketing/CRM workflow, non-technical owner, < 50k ops/mo	Make.com
Stateful logic, LLM chain, atomic writes	Plain TypeScript + Cloudflare Worker

That's the decision tree. It'll change. Drop a line if your experience is different.

Get in touch if you want help making the call for a specific workflow.