n8n, Make, and custom agent builds sit on a spectrum from self-hosted/technical to hosted/visual to fully bespoke — the right choice depends on team size, process complexity, integration surface, budget, and whether self-hosting or compliance requirements rule out a SaaS platform outright.
There's no universally "best" answer here, and any vendor who tells you otherwise is selling, not advising — this is a scoring exercise against your own constraints.
How do the three options score across the factors that actually matter?
| Factor | n8n | Make | Custom agents | |---|---|---|---| | Team size fit | Small-to-mid teams comfortable with a technical tool | Small-to-mid teams wanting a polished visual builder | Mid-to-large teams with engineering capacity | | Process complexity | Handles complex branching well, code nodes available | Best for moderate complexity; deep custom logic gets awkward | Handles arbitrary complexity, including multi-agent reasoning | | Integration surface | Wide, plus self-hosted webhook flexibility | Wide, strong pre-built app connectors | Unlimited — build to any API or legacy system | | Budget | Free self-hosted tier; paid cloud tiers moderate | Subscription-based, scales with operations/usage | Highest upfront, lowest marginal cost at scale | | Self-host / compliance | Yes — full self-hosting available | Limited — primarily cloud-hosted | Yes — full control over hosting and data |
What does 24-month total cost of ownership actually look like?
| Cost category | n8n (self-hosted) | Make | Custom agents | |---|---|---|---| | License / subscription | Low (infra cost instead) | Low-to-moderate, scales with usage | None (no per-seat license) | | Infrastructure | Moderate (you host it) | None (hosted for you) | Moderate-to-high (your infra or cloud) | | Maintenance | Moderate (you own upgrades) | Low (vendor-managed) | High (your team owns the code) | | 24-month total | Low-moderate | Moderate | Highest, but lowest marginal cost per additional workflow |
Three scenario verdicts
A 50-person distributor automating order and invoice workflows → Make. Small team, no dedicated engineering function, moderate process complexity across well-supported SaaS apps (ERP-lite, accounting, email). Make's visual builder and managed hosting remove the operational burden a team this size shouldn't be carrying.
A 300-person manufacturer with an on-prem ERP → n8n, self-hosted. Compliance and data-residency requirements rule out a SaaS-only platform; n8n's self-hosting option plus its code-node flexibility handles the on-prem integration surface a hosted-only tool can't reach.
A team building a multi-system reasoning workflow (agent that plans across CRM, inventory, and finance data with genuine judgment calls) → custom agents. Neither n8n nor Make is built for genuine multi-step reasoning with memory and dynamic tool selection — past a certain complexity threshold, a custom agent framework is the only option that doesn't fight the tool.
How do you migrate between these platforms later?
Migration paths run in the direction of increasing complexity, and rarely the reverse:
- Make → n8n: typically triggered by hitting a compliance or self-hosting requirement Make can't meet, or outgrowing Make's per-operation pricing at high volume. Workflow logic usually ports conceptually even though the tools aren't directly compatible.
- n8n → custom: typically triggered by needing genuine multi-agent reasoning or memory across sessions that a workflow-automation tool (even a flexible one) isn't architected for.
- Custom → a platform: rare, but happens when a bespoke build's maintenance burden exceeds its complexity justification — sometimes the honest fix is admitting the process didn't need a custom agent after all.
If you're migrating an existing RPA estate rather than choosing a greenfield platform, our RPA-to-agent migration playbook covers where each of these options fits into that specific process.
Why does this matter beyond picking a tool?
This decision also signals what kind of automation partner you need: a vendor pushing one platform regardless of your constraints is optimizing for their own delivery model, not your fit. We build on n8n, Make, and custom agent frameworks depending on what the client's actual constraints require — see our agentic automation service for how we scope that decision during discovery.
What questions should you ask a vendor before they pick a platform for you?
Ask these before signing anything, and be wary of a vendor who can't answer them plainly:
- Why this platform for our specific process, not just "it's what we always use"? A good answer references your team size, complexity, and compliance needs — not the vendor's own delivery preferences.
- What does exit look like if we outgrow this platform? Every platform has a ceiling; a vendor who hasn't thought about your migration path hasn't thought past the first invoice.
- Who operates this day-to-day once you're gone? Self-hosted n8n needs someone to own upgrades; Make needs someone to own the subscription and workflow sprawl; a custom build needs someone who can read the code.
- What's the real 24-month cost, not just the pilot cost? Pilot pricing is often subsidized or scoped narrow; ask for the run-rate at your expected production volume.
A vendor who welcomes these questions is signaling confidence in their recommendation; one who deflects them is signaling the opposite.
Key Takeaways
- Score all three against your own team size, process complexity, integration surface, budget, and self-hosting/compliance needs — there's no universal winner.
- 24-month TCO: n8n self-hosted and Make are both lower-cost than custom builds upfront; custom agents have the highest initial cost but the lowest marginal cost at scale.
- Rule of thumb: small teams on well-supported SaaS → Make; compliance/on-prem constraints → n8n self-hosted; multi-system reasoning → custom agents.
- Migration paths generally run toward more complexity (Make → n8n → custom) as requirements outgrow each tool's ceiling.