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 touches customer-facing or compliance-adjacent data, or has to live on infrastructure you control.
• Use custom Claude (a small backend on the Anthropic SDK) 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's almost always the wrong question. The right question is what the workflow has to survive: staff changes, vendor changes, scale changes, the regulator asking in writing why a decision was made two years from now. Answer that, and the tool picks itself.

We use all three, often for the same client, sometimes in the same workflow. Here is the 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, connect them with lines, authenticate the integrations, and ship. It's fast to build in, has well over a thousand pre-built connectors, and runs on Make's hosted infrastructure. You can build something genuinely powerful in an afternoon, which is both its main feature and its main risk.

n8n is structurally similar, visual and node-based, but it's open source and self-hostable. You run it on your own infrastructure, you own the database where your workflow logic lives, and it has a real escape hatch: custom JavaScript nodes when the visual layer runs out.

Custom Claude means a small backend service that calls the Anthropic API directly, usually FastAPI or similar on your own infrastructure. It's what you use when the workflow involves real model reasoning rather than rule-based plumbing: multi-step logic, prompt orchestration, dynamic tool use, retrieval against your own data. The stuff Make and n8n can technically do but shouldn't.

The decision rule

Answer these in order and 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, and let the team iterate on it themselves.

This is the class of work where Make earns its place: enriching leads before they hit the CRM, generating a weekly report from a couple of data sources, routing form submissions to the right person's Slack. Things that, if they break for an hour, nobody dies. For workflows where the cost of going down for a day is "we'll do it manually for a day," Make's hosted convenience is the right trade.

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

Use n8n, self-hosted. Or build it custom. Don't use Make.

This is the cut that matters most. Picture a property management firm running a tenant-facing automation on Make, and a privacy regulator asking, in writing, where tenant data is processed. The honest answer is "Make's hosted servers, somewhere." Sometimes that answer is acceptable. Increasingly, it isn't, and unwinding it after the fact is months of work.

n8n solves this cleanly. It runs on your own VPS or inside your own cloud, and the database that holds workflow state is yours: inspectable, auditable, exportable. We default to n8n for anything tenant-facing, anything in healthcare, and anything where "where does this data live?" might one day need a formal answer.

3. Is the core of the workflow rule-based plumbing, or model reasoning?

Plumbing, meaning "when X happens, do Y, then Z": use n8n. The visual model is genuinely good for branching logic, retries, integration fan-out, and conditional routing.

Model reasoning: build it custom. This is the cut almost everyone gets wrong. Building agentic logic inside a visual editor is technically possible and operationally terrible. You end up with a 47-node flowchart nobody can read, the actual reasoning smeared across eight nodes and three prompt fields, and a failure mode of "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. Ours is usually FastAPI, a thin Postgres state layer, and the Anthropic SDK, a few hundred lines in total. The prompts live 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 lean on a vertical-specific API that no pre-built connector covers well?

Write a thin custom client for that API, and call it from whichever orchestration layer you're using.

This is the case for property managers on Buildium, brokerages on the MLS, clinics on an EMR. The pre-built connector, where one exists, covers a fraction of the operations you'll want and papers over the auth complexity in ways that hide real bugs. A few hundred lines of Python that handle auth, retries, rate limits, and webhook validation properly is the right abstraction, and it outlives every tool decision above it. (You can see where this fits in a real build in [anatomy of a four-week build](/blog/anatomy-of-a-four-week-build).)

What we never use these for

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

• Anything with sub-second latency requirements. None of them are real-time systems.
• Anything processing more than a few thousand records a minute. They'll technically run. They won't scale gracefully.
• Anything where a single wrong output is expensive: medical recommendations, financial trades, legal opinions. The orchestration tool is irrelevant there; you need a different architecture with explicit human checkpoints.
• Anything so simple that a cron job or a database trigger would do. Don't add an automation platform because automation platforms are interesting. Add one because it earns its keep.

The underlying principle

Make optimizes for speed of construction. n8n optimizes for ownership of the deployment. Custom code optimizes for control of the logic. Know which of the three matters most for the workflow in front of you and the choice makes itself.

The mistake is picking the tool first, usually because it's the tool the team already knows, and bending every workflow to fit it. Once that happens, every problem the business meets for the next two years gets framed as a problem for that tool. The tool is the last decision, not the first. (Working out which workflows are worth automating at all is what [the five questions every audit answers](/blog/five-questions-every-audit-answers) is for.)

The rule, condensed

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 the workflow is genuinely plumbing-heavy.
3. Custom Claude if the model is doing real reasoning, not playing a fancy if-then.
4. Thin custom wrappers for vertical APIs, whatever sits on top.

Most of the builds we ship use two of the three together, and the boundary between them is the real architecture decision. Not the choice of any single tool.