After 47 production AI workflow deployments at Openclaw clients (2024–2026), the n8n vs Make.com vs Custom decision is no longer a religious debate — it’s a 4-question decision tree with predictable answers. n8n wins when you have <50 daily executions and need a visual builder. Make.com wins when you have a non-technical operator owning the workflow. Custom code wins everywhere else — and that “everywhere else” is 70% of real client cases. Here’s the framework, the hidden costs of each, and 2 anonymized case studies showing why.
Why is the n8n vs Make.com vs Custom debate even a thing in 2026?
The debate exists because the marketing of low-code platforms systematically hides the operational tax — server overhead, execution caps, debugging time, and the 6–12 month “rebuild it in code anyway” inflection point. The default answer most agencies give (“use Zapier / use Make / use n8n”) is correct ~30% of the time and catastrophically wrong the other 70%. The right answer depends on 4 variables that nobody bothers to ask the client.
We’ve shipped workflows on all three (n8n self-hosted, n8n cloud, Make.com Pro tier, Make Enterprise, custom Python/TypeScript on Railway). We’ve also rebuilt 6 client workflows from n8n/Make to custom because the original choice cracked under scale. Below is the framework we now use to avoid the rebuild.
What’s the 4-question decision tree?
The tree is dichotomous and brutally simple. Each question eliminates one option. No middle ground, no “it depends” cop-out.
Q1 — Will the workflow execute >50 times/day in steady state?
└─ YES → Skip n8n/Make. Go to Q3 (Custom).
└─ NO → n8n or Make are viable. Go to Q2.
Q2 — Will a non-technical operator own the workflow long-term?
└─ YES → Make.com (better UX, easier handover).
└─ NO → n8n self-hosted (cheaper, more flexible, devs can fork it).
Q3 — Does the workflow require >3 LLM calls in sequence with branching logic?
└─ YES → Custom code, period. n8n/Make collapse on agentic flows.
└─ NO → Go to Q4.
Q4 — Are there strict latency requirements (<2s end-to-end response)?
└─ YES → Custom code (n8n/Make add 800ms–2s overhead per node).
└─ NO → n8n self-hosted is workable for high-volume non-agentic.
Decoded: about 70% of our client workflows hit Q3 = YES (>3 LLM calls with branching) → custom code wins. Of the remaining 30%, half hit Q2 = YES (non-tech owner) → Make.com. The remaining 15% are split between n8n self-hosted (devs in the loop, low volume) and n8n cloud (rare — usually a stop-gap).
What does each option actually do well?
Each platform has a clean, defensible sweet spot. Below is what they’re genuinely best at when used in their lane.
| Platform | Sweet spot | Strength |
|---|---|---|
| n8n self-hosted | Internal dev tooling, ETL, glue between APIs | Free, self-hosted, 400+ nodes, version control via JSON export |
| n8n cloud | Quick prototypes, demos | Hosted, no DevOps, fast time-to-first-workflow |
| Make.com | Operations team owns workflow, visual debugging | Best UX of the three, error handling visual, scenario library |
| Custom code | Production agents, tool-use loops, anything >50/day | Full control, lowest cost-at-scale, debuggable by devs |
The mistake we see most often: clients pick n8n cloud or Make for a workflow that will hit 10 000 executions/month within 6 months, then discover the platform’s monthly operations cap (Make: 10K Pro / 40K Teams) and have to upgrade 3 tiers or rebuild. That’s a 6–9 month detour costing $4K–$12K in wasted effort.
What are the hidden costs nobody mentions?
Each platform has a “tax” that isn’t on the pricing page. After 47 deployments, the pattern is consistent.
n8n self-hosted hidden costs
- DevOps overhead: $20–$80/month for a Hetzner VPS or Railway service + Postgres + Redis. Not zero.
- Backup discipline: workflows live in JSON in a Postgres DB. If you lose the DB, you lose the workflows. Most teams forget to backup until the first crash.
- Upgrade pain: breaking changes between major versions (v0.x → v1.x was rough). Plan 1–2 days per major upgrade.
- Debugging at scale: when 4 000 executions run overnight, finding the 3 that failed in the n8n UI is painful. You’ll end up writing a custom error-aggregation script — which is custom code.
Real cost on a serious deployment: ~$200/month all-in (infra + maintenance time). Not the $0 the marketing implies.
Make.com hidden costs
- Operations cap is per-scenario per execution, not per workflow run. A scenario with 8 modules counts as 8 ops. Read the fine print. A “10K ops” Pro plan delivers ~1 200 actual workflow runs.
- HTTP-based modules eat operations fast: every API call is 1 op. Aggressive workflows blow through caps in 4–7 days.
- Pricing tiers are aggressive past Pro: Pro $16/mo → Teams $29/mo → Enterprise (call us, $200+/mo). The jump from Teams to Enterprise hits brutally.
- Vendor lock-in: there’s no JSON export of scenarios that runs anywhere else. If you leave Make, you rebuild from scratch.
Real cost on a serious deployment: $80–$300/month + the rebuild risk if you outgrow Enterprise.
Custom code hidden costs
- Engineering hours upfront: $4K–$15K to build what n8n/Make does in 1 day. Not negotiable.
- Maintenance: 0.5–2 hours/week for monitoring, tweaks, occasional bug fixes. Compounds with workflow count.
- DevOps: same as n8n self-hosted (Railway + Supabase + cron). $80–$250/month at production scale.
- Documentation discipline: if the dev who built it leaves, you need a runbook. Always.
Real cost: $80–$250/month at run time + 1–2 hours/week of dev attention + the upfront build investment. Linear-cheap at scale, but never zero.
When did we choose n8n at a real client?
A French B2B agency (anonymized) needed an internal workflow for their sales team: enrich every new HubSpot lead with company data from 4 sources (Apollo, Clearbit, LinkedIn scrape, a custom database), score it against 6 criteria, push the result back to HubSpot, and notify Slack if score >70. Volume: 30–50 leads/day in steady state. Owner: their CTO (technical, comfortable with JSON).
We built it on n8n self-hosted (Railway + managed Postgres). Why:
| Reason | Detail |
|---|---|
| Volume <50/day | Far below the inflection where n8n breaks down |
| CTO owns it | Will tweak nodes and read JSON without us |
| 4 API integrations | All have native n8n nodes; zero custom code needed |
| 1 LLM call (scoring) | Single node, no branching agentic logic |
| Budget tight | Build was $1 800 vs $5 500 for custom equivalent |
Result after 8 months: runs flawlessly, ~36 leads/day, $30/mo Railway infra. CTO has tweaked the scoring rubric 4 times without our involvement. This is the n8n win pattern.
When did we choose Custom Code at a real client?
A LATAM dropshipper (anonymized) needed: ingest ad spend from Meta + TikTok + Google, scrape Dropi remittances + 99minutos delivery status (no API), reconcile against Shopify orders, run a daily P&L per SKU, generate kill-signals for losing ad sets, and post a Telegram digest at 8 a.m. Volume: ~2 000 daily computations + 4 cron jobs + 1 LLM call per kill-signal explanation.
We built it on custom TypeScript on Railway + Supabase + Browserbase. Why:
| Reason | Detail |
|---|---|
| Volume >>50/day | n8n/Make would hit cost or throughput ceiling in month 2 |
| Browserbase + Stagehand integration | No native nodes in n8n/Make; would require custom HTTP nodes anyway |
| Daily P&L computation | Complex SQL + denormalized tables; n8n’s data manipulation tools collapse |
| Operator wants kill-signals via Telegram | Custom message formatting + threading; trivial in code, painful in n8n |
| 3-year horizon | Run-cost on Make Enterprise would be $300–$500/mo; custom is $150/mo |
Result after 6 months: ~5 100 $ ad-spend recovered in month 1, run-cost stable at $150/mo, dropshipper owns the code on his GitHub. This is the custom win pattern.
What’s the comparison table on the variables that matter?
We graded all 3 options on the 8 variables that actually drive the decision. Bias-free, based on production observation.
| Variable | n8n (self-host) | Make.com | Custom code |
|---|---|---|---|
| Visual builder | ✓ | ✓ (best UX) | ✗ |
| Self-hostable | ✓ | ✗ | ✓ |
| Version control (Git) | ✓ (JSON export) | ✗ | ✓ (native) |
| AI-native nodes (LLM tools) | Partial (HTTP wrappers) | Partial | ✓ (full SDK) |
| Cost per 10K executions | ~$0.05 (infra amortized) | ~$3.50 | ~$0.10 |
| Time-to-build (1st workflow) | 4–8h | 2–4h | 16–40h |
| Time-to-modify (existing workflow) | 30 min | 15 min | 1–4h |
| Failure recovery / debug | Painful at scale | Best built-in | Best (your own logs) |
| Scales past 50K exec/day | Yes (with tuning) | No (cap) | Yes |
| Vendor lock-in | None | Total | None |
The tradeoff is clear: Make.com wins on UX and time-to-build, custom wins on scale and cost-at-volume, n8n wins on the middle ground (technical owner, low-medium volume, no lock-in). Pick by use case, not by ideology.
What’s the recurring failure mode we see?
The most common failure is “we’ll use n8n / Make to ship fast, then migrate to custom if needed.” It almost never happens in practice. What happens instead: the workflow runs for 4–8 months in n8n/Make, accumulates implicit business logic in 27 nodes nobody documented, and then the migration to custom takes 3–4× longer than building custom from scratch because you’re reverse-engineering rather than designing.
If you suspect from day 1 that the workflow will exceed Q1’s 50/day threshold or hit Q3’s >3 LLM calls, just build custom from day 1. The 8–10 days of upfront engineering save 4–6 weeks of migration pain in month 8.
The exception: prototypes for product validation. If the workflow is “we want to test if our ICP cares about X,” n8n cloud or Make is correct — the goal is learning, not scale. Throw it away after 30 days regardless of result.
What’s the 2026 update — does AI-first tooling change the calculus?
Yes, modestly. Two new patterns matter:
- Code-generation IDEs (Cursor, Continue, Codex CLI) have collapsed the time-to-build for custom code by 40–60%. A workflow that took 16h to code in 2024 takes 6–9h in 2026. This shifts the break-even point earlier — custom now wins at lower volumes than before.
- n8n added native AI agent nodes in v1.40+ (LangChain integration, vector store nodes). For 1–2 LLM call workflows, n8n is now genuinely competitive with custom on AI tasks. But it still collapses on >3-step agentic loops with branching, because the visual debugger isn’t built for that.
Net effect: custom wins more often than it did 18 months ago, n8n closed some of the gap on AI workflows, and Make.com remains best-in-class for non-tech operator handover. Make.com hasn’t moved much — that’s their strategic position and they’re sticking with it.
What should you ask before picking a platform in 2026?
The single question that beats every other framework: “Who will own this workflow 12 months from now, and what will they do when it breaks at 3 a.m. on a Saturday?”
If the answer is “the founder, who can read JSON and wake up at 3 a.m.” → n8n. If the answer is “an ops manager who’ll click around and call a freelancer” → Make.com. If the answer is “a dev team with on-call rotation, monitored alerts, and a runbook” → Custom code. If the answer is “I don’t know” → Don’t ship the workflow yet. The “who owns it” question is the entire decision.
Sources: Openclaw internal data on 47 production workflow deployments (2024–2026). n8n self-hosting docs. Make.com pricing. Operation cap math verified against Make Pro plan limits. Cost-per-execution benchmarks measured on identical workloads (10K runs, simple HTTP+LLM pipeline) across the 3 platforms in March 2026.