Make.com vs n8n: which one to build on

Both are visual automation platforms. Both connect apps, transform data and run workflows on triggers. The differences that matter are about ownership, cost shape and how they behave when things go wrong.

Make.com

What it is: a hosted platform. You build in the browser, they run it, you pay per operation.

Strengths:

• Fastest path to working. Large connector library, clean visual builder, good defaults.
• No infrastructure. Nothing to host, patch or monitor.
• Genuinely good error handling once you learn it, with retries and fallback routes.
• Excellent for teams where not everyone is technical.

Where it hurts:

• Operations pricing. Every module execution counts. A workflow with eight modules running a thousand times is eight thousand operations. Costs scale with complexity, not just volume, which surprises people.
• Debugging opacity. Errors are sometimes reported by symptom rather than cause. I lost a week to a validation error that named a count of failing parameters but not which ones.
• Silent scenario disabling. Hit consecutive errors and Make switches the scenario off — while the webhook keeps accepting data and returning success. Your front end shows a green tick and nothing runs.

That last one is worth knowing before it happens to you. I wrote about it in four things that broke while I built my first serious AI automation.

n8n

What it is: open source. Self-host it, or use their cloud.

Strengths:

• Cost shape. Self-hosted, you pay for a server, not per operation. For high-volume workflows this is dramatically cheaper.
• Data ownership. Everything stays on your infrastructure — genuinely relevant for POPIA and GDPR positions.
• Code when you need it. Drop into JavaScript or Python inside a node without leaving the workflow.
• No arbitrary limits. Complexity doesn't cost extra.

Where it hurts:

• You're the operations team. Hosting, updates, backups, uptime. That's real work with real risk.
• Steeper learning curve. More power, less hand-holding.
• Smaller connector library than Make, though it's grown a lot and HTTP nodes cover the gaps.

How I actually choose

Make when: the workflow is client-facing and someone else may need to maintain it; volume is modest; speed to working matters more than long-run cost; the team isn't technical.

n8n when: volume is high enough that per-operation pricing bites; data can't leave your infrastructure; the logic needs real code; you're comfortable running a server.

A rough threshold: if a workflow will run more than about 10,000 operations a month, model both costs before committing. The crossover arrives sooner than people expect.

The thing that matters more than the choice

Both platforms will let you build something fragile.

The failure mode isn't picking the wrong tool. It's building a workflow with no error handling, no documentation, and no monitoring — so when it breaks silently, nobody notices for three weeks.

Whichever you choose:

• Handle errors explicitly. Decide what should happen when a step fails, rather than letting the whole run die.
• Alert on failure. If a workflow matters, you need to know when it stops.
• Document it. Future you will not remember why that filter exists.
• Test with bad data. Real inputs are messier than your test payload.

The tool is a detail. The discipline is the product.