The Setup Most Teams Start With

When a team first looks at workflow automation, the comparison usually gets framed as Make versus Zapier versus n8n. The honest version of that conversation, the one happening in r/n8n threads and on Hacker News, narrows quickly to Make versus n8n. Zapier sits in a different lane for most practitioners, more expensive per task, less flexible on the technical side, and rarely the choice for anything beyond trivial integrations.

What people expected going in was a clean split. Make would win on polish and ease. n8n would win on flexibility and price. After six to twelve months of production use, the picture that emerges from community discussions is messier and more interesting.

What Practitioners Expected vs What They Got

The dominant narrative on Reddit and YouTube heading into 2026 was that Make had the better onboarding story. The visual editor is genuinely cleaner, the connection library is broader, and the documentation reads like it was written for someone who has never opened a terminal. Developers on r/LocalLLaMA and r/n8n consistently noted that n8n’s first impression feels like configuring a self-hosted service, which it is.

The surprise was what happens at month three. Practitioners running Make scenarios at scale started reporting operation-count anxiety. A single scenario that fans out across 50 records and hits five APIs can consume 250 operations in one run. The Make pricing tiers are public, and the math gets uncomfortable fast. Multiple threads on r/automation showed users hitting the 10k operations ceiling within weeks of moving a real workload off Zapier.

n8n users reported the opposite surprise. The self-hosted version is free, but the real cost is engineering time. Setting up n8n on a VPS, wiring up a database, configuring credentials, and handling webhook reliability takes days, not hours. Practitioners on HN pointed out that n8n’s “free” pricing assumes you have someone who knows what a reverse proxy is.

Where Make Genuinely Delivers

Make has a real strength in business-facing workflows where the operator is not a developer. Practitioners running marketing ops, sales ops, and finance automation consistently pick Make for these scenarios. The reasons are concrete.

The error handling is more forgiving than n8n’s. When a scenario hits a rate limit or a transient API failure, Make’s built-in retry and break modules handle it without custom code. n8n requires you to build retry logic into the workflow or rely on the community-built nodes that may or may not cover your edge case.

The connection library is wider for SaaS tools that matter to non-technical teams. HubSpot, Salesforce, Shopify, Stripe, and Google Workspace all have first-party Make apps with deep feature coverage. n8n’s equivalents exist but are often community-maintained, which means version lag when the upstream API changes.

Latency for typical scenarios is in the 800ms to 2s range per operation, which is fine for human-paced workflows. The Make infrastructure handles concurrent scenario execution well, with documented support for thousands of parallel runs on the higher tiers.

For teams running 1k to 50k operations per month, Make’s pricing is competitive. The Teams plan at roughly $16 per month for 10k operations covers a lot of real workloads. The pain starts above 100k operations per month.

Where n8n Genuinely Delivers

n8n’s strengths show up in the places developers care about. The Code node lets you write JavaScript or Python inline, which means you can do transformations that would require a custom function module in Make. Practitioners building data pipelines, AI agent orchestration, or anything that touches a database reach for n8n first.

The self-hosted version removes the per-operation cost ceiling entirely. A team running 500k operations per month on n8n Cloud’s enterprise tier pays roughly $2k per month, but the same workload on a self-hosted n8n instance on a $50/month Hetzner box costs nothing beyond the engineering time to maintain it. Multiple HN commenters noted that this math is what convinced their teams to switch.

n8n’s AI and LLM integration is ahead of Make’s. The native LangChain nodes, vector store connectors, and agent workflows were added earlier and are more deeply integrated. Practitioners building RAG pipelines or multi-agent systems consistently report that n8n is the only one of the two that handles these patterns without bolting on external services.

Webhook handling is more reliable on n8n. The self-hosted version gives you full control over the queue, retry behavior, and timeout settings. Make’s webhook scenarios are easier to set up but harder to debug when something goes wrong, because the execution logs are limited on lower tiers.

The community is unusually active. The n8n Discord has thousands of practitioners sharing workflow templates, and the GitHub issues get responses from the core team within days. Make’s community is more focused on the business user, which is appropriate for the product but less useful when you are debugging a custom integration at 11pm.

Where Make Falls Short

The operation pricing model is the most common complaint. Practitioners on r/automation have posted detailed breakdowns showing that a single complex scenario can consume 5x to 20x the operations a naive estimate suggests. The fan-out, the iterator modules, and the search-and-update operations all count separately.

Custom integrations require HTTP modules and JSON parsing, which works but feels bolted on. Make’s HTTP module is functional but limited compared to n8n’s, where you can write the full request in code and handle the response with the same flexibility.

The execution history on lower tiers is capped at 30 days, which makes debugging intermittent failures painful. Practitioners running production workloads report paying for the higher tier specifically to get longer history.

Version control is essentially absent. Make scenarios live in the platform, and there is no Git integration. Teams that care about change tracking, rollback, or peer review of workflow changes find this limiting. Multiple threads on r/n8n mentioned this as the deciding factor for technical teams.

Where n8n Falls Short

Onboarding is the biggest gap. A non-technical user opening n8n for the first time faces a wall of concepts: credentials, nodes, expressions, the data structure tree, and the workflow execution model. Make’s UI hides most of this complexity behind defaults.

The community-maintained nodes are a double-edged sword. They cover gaps in the official library, but they lag behind upstream API changes. Practitioners have reported scenarios breaking because a community node for a SaaS tool was not updated when the API changed. The workaround is to use the HTTP node directly, which negates the convenience.

Self-hosting reliability is your problem. Practitioners on r/selfhosted have posted detailed guides on running n8n with PostgreSQL, Redis for queue mode, and a reverse proxy for webhooks. The setup works, but it requires someone who understands these components. When the queue fills up or the database connection drops, you are debugging infrastructure, not workflows.

The UI is functional but rougher than Make’s. Layout issues, occasional node rendering bugs, and less polished error messages are common complaints. For a tool that costs nothing to self-host, this is acceptable. For a team paying $50 to $800 per month for n8n Cloud, the polish gap with Make is noticeable.

Who Each Tool Fits Best

Make fits teams of 2 to 10 people running business workflows where the operator is not a developer. Marketing ops, sales ops, finance automation, and customer success workflows are the sweet spot. The budget is predictable, the onboarding is fast, and the maintenance burden is low.

n8n fits teams of 3 to 20 people with at least one technical operator. The sweet spot is anything that involves custom logic, data transformation, AI workflows, or integration with internal services. Engineering teams, data teams, and AI-focused builders reach for n8n first.

The overlap zone is interesting. Teams running both Make and n8n is a common pattern. Make handles the business-facing workflows that non-technical operators maintain. n8n handles the technical workflows that developers maintain. The two tools talk to each other through webhooks, with each handling what it does best.

What Teams Commonly Pair With or Replace Them With

The most common pairing is Make or n8n with a vector database for AI workflows. Practitioners building RAG pipelines use n8n for the orchestration and Pinecone, Weaviate, or Qdrant for the storage. Make can do this but requires more custom HTTP work.

For teams replacing Make, the most common move is to n8n when operation costs become painful or when the team needs more technical flexibility. The migration is not trivial, because the workflow paradigm is different, but practitioners report the long-term cost savings justify the effort.

For teams replacing n8n, the move is usually to a custom codebase. Once a workflow reaches a certain complexity, the maintenance burden of keeping it in n8n exceeds the cost of writing it as a proper application. The threshold varies, but practitioners on HN have cited workflows with 30+ nodes and complex branching as the point where they pull the logic out.

The hybrid pattern that emerged in 2025 and 2026 is to use n8n for prototyping and Make for production. Teams build the workflow in n8n because the iteration speed is faster, then rebuild it in Make once the logic stabilizes. This is unusual but reported by multiple practitioners.

The Honest Summary

The Make versus n8n decision is not about which tool is better. It is about which tool matches the operator profile and the workload shape. Make wins on polish, onboarding, and business-user workflows. n8n wins on flexibility, cost at scale, and technical workflows.

The community signal is consistent on this point. Practitioners who picked the wrong tool report the same regret. Teams that picked the right tool for their context report high satisfaction with either choice.

The mistake to avoid is treating this as a feature comparison. The features overlap more than the marketing suggests. The real differentiator is who will be building and maintaining the workflows, and what happens when the workload grows past the initial estimate.

If you’re working through which tools belong in your stack, book a 60-min Omni Audit, https://calendly.com/sam-mckay/discovery-call