Make.com vs n8n vs custom Claude — when to use what

Key takeaways

• The tool choice is the last decision, not the first. Start with what the workflow has to survive — staff changes, vendor changes, the regulator's question two years from now — and back into the tool.
• Use Make.com for low-stakes, single-team workflows the team will iterate on themselves.
• Use n8n (self-hosted) when the workflow processes customer-facing or compliance-adjacent data, or needs to live on infrastructure you control.
• Use custom Claude (FastAPI + Anthropic SDK + Postgres) when the workflow involves real model reasoning rather than rule-based plumbing. Don't build agentic logic inside a visual no-code editor.
• Wrap vertical-specific APIs (Buildium, MLS, EMRs) in thin custom clients regardless of which orchestration layer sits on top.

The wrong question

The question we get asked most often, in some form, is "should we use Make, or n8n, or build it custom?" It is almost always the wrong question. The right question is what the workflow has to survive — staff changes, vendor changes, scale changes, the regulator's question two years from now about why a decision was made — and then back into the tool from there.

We use all three. Often in the same client. Sometimes in the same workflow. Here is the actual rule we apply, in the order we apply it.

The three tools, briefly

Make.com is a no-code visual automation platform. You drag boxes, you connect them with lines, you authenticate the integrations, and you ship. It is fast to build in, has 1,500+ pre-built connectors, and runs on Make's hosted infrastructure. It is also a tool where you can build something genuinely powerful in a few hours, which is both its main feature and its main risk.

n8n is structurally similar — visual, node-based, integration-heavy — but it is open-source and self-hostable. You can run it on your own infrastructure, modify the source, and (importantly) you own the database where all your workflow logic lives. It has fewer pre-built integrations than Make, but it has a coding escape hatch (custom JavaScript nodes) that Make does not.

Custom Claude — by which we mean a custom backend service that calls the Anthropic API directly, usually wrapped in FastAPI or similar, deployed on your own infrastructure — is what you use when the workflow involves real model reasoning rather than rule-based plumbing. Multi-step agentic logic, complex prompt orchestration, dynamic tool use, retrieval-augmented generation against your own data: the stuff Make and n8n can technically do but shouldn't.

The decision matrix

Here is the rule we use. The rule is sequential — answer in order, stop at the first yes.

1. Is this workflow non-critical, used by one team, and unlikely to scale past a few hundred runs a month?

Use Make. Build it in an afternoon. Ship it. Let the team iterate on it themselves. Don't over-engineer.

Examples we've shipped on Make: lead enrichment for a 40-agent brokerage, weekly owner report generation for a small property portfolio, a triage that routes form submissions to the right teammate's Slack DM. Things that, if they break for an hour, nobody dies.

The reason to use Make for this class of work is that Make is the fastest path from "this is annoying" to "this is automated." For workflows where the cost of going down for a day is "we'll handle it manually for a day," Make's hosted convenience is the right trade.

2. Does the workflow involve customer-facing or compliance-adjacent data, or does it need to run inside your own infrastructure for legal, contractual, or data-residency reasons?

Use n8n, self-hosted. Or build it custom. Do not use Make.

This is the cut we see most often. A property management firm runs a tenant-facing automation on Make. The Canadian privacy regulator's office asks them, in writing, where tenant data is being processed. The answer is "Make's hosted servers, somewhere." That answer is sometimes acceptable, increasingly often it isn't, and the firm now has six months of remediation work to move the workflow somewhere they can stand behind.

n8n solves this cleanly. You run it on your own VPS or inside your own cloud. The database that holds workflow state is yours. Inspectable, auditable, exportable. We default to n8n for anything tenant-facing, anything in healthcare, anything where the question "where does this data live?" might have to be answered to a regulator.

3. Is the core of the workflow rule-based plumbing — "when X happens, do Y, then Z" — or is it model reasoning?

Rule-based plumbing → n8n. The visual model is correct for branching logic, retries, integration fan-out, and conditional routing. You can build extraordinary things in n8n if the workflow shape is plumbing.

Model reasoning → custom Claude. This is the cut almost everyone gets wrong. Building agentic logic — multi-step planning, tool use, dynamic routing of the model's own decisions — inside a no-code visual editor is technically possible and operationally terrible. You end up with a 47-node flowchart that nobody can read, where the actual reasoning is split across eight nodes and three prompt fields, and the failure mode when something goes wrong is "we don't know."

When the work is "the model decides what to do next based on what it found in step one," wrap the Anthropic API in a backend you control. We use FastAPI + a thin Postgres state layer + the Anthropic SDK. The whole thing is usually 200–600 lines of code. It is inspectable in version control. The prompts are in files, not in node forms. The decisions are logged. When the system does something surprising six months from now, you can read the code and find out why.

4. Does the workflow integrate with one or two vertical-specific APIs that nobody else's pre-built connector covers well?

Build it custom. Specifically: build a thin Python or Node service that wraps the vertical API, and call it from whichever orchestration layer you're using.

This is the case for property managers integrating with Buildium, for brokerages integrating with the MLS, for clinics integrating with EMR systems. Make's Buildium connector exists; it covers maybe 40% of the operations you'll actually want, and it papers over the auth complexity in a way that hides real bugs. Better to write a 300-line Python client that handles auth, retries, rate-limiting, and webhook validation properly, then call it from n8n nodes or from a custom backend. The thin wrapper is the right abstraction. The pre-built connector is the wrong one. (We walk through what this looks like in production in [a case study of a four-week build for a 22-unit property manager](/blog/22-unit-property-manager-cuts-18-hours).)

What we never use these for

A short list of cases where none of these three tools is the right answer:

• Anything mission-critical with sub-second latency requirements. None of them are real-time systems.
• Anything that processes more than a few thousand records per minute. They will technically run; they will not scale gracefully.
• Anything where the cost of a single wrong output is high — medical recommendations, financial trades, legal opinions. The orchestration tool is irrelevant; you need a different architecture entirely, with explicit human-in-the-loop checkpoints and a different evaluation regime.
• Anything where the workflow is genuinely simple and a database trigger or a cron job would do the same thing. Don't add an automation platform because automation platforms are interesting. Add them because they earn their keep.

The underlying principle

The reason we use all three is that the three tools optimize for three different things, and most workflows fit one of them cleanly.

Make optimizes for speed of construction. n8n optimizes for ownership of the deployment. Custom code optimizes for control of the logic. If you know which of those three things matters most for the workflow you're about to build, the tool picks itself.

The mistake is picking the tool first — usually because it's the tool the team already knows — and then bending the workflow to fit. We have seen six-month engagements stuck on Make because the firm's first hire happened to be a Make consultant, and every problem the firm encountered for the next two years was framed as a Make problem. The tool is the last decision, not the first one. (Working out which workflows are even worth automating in the first place is what [the five questions every audit answers](/blog/five-questions-every-audit-answers) is for.)

The rule

When in doubt, the order is:

1. Make if it's small, low-stakes, and the team will own it directly.
2. n8n if it needs to live on your infrastructure or if the workflow is genuinely plumbing-heavy.
3. Custom Claude if the model is doing real reasoning, not just being a fancy "if-then."
4. Thin custom wrappers for vertical APIs, regardless of which orchestration layer is on top.

Three tools. One ordered rule. Most of the engagements we ship use two of the three together, and the boundary between them is the actual architecture decision. Not the choice of any single tool.