Short answer: use Make when the work is a handful of straightforward hops between SaaS apps, the volume is modest, and nobody will ever be audited on it. Use n8n when you need real logic, self-hosting, custom code inside steps, and the ability to keep workflows in version control. Commission a custom build when the process is core to how the business makes or protects money — when it touches regulated data, has to survive partial failure without a human noticing, needs an audit trail that satisfies a controller or an examiner, or runs at volumes where per-operation platform billing stops making sense.
The honest version is that most organizations end up with two of the three. A low-code platform is the right tool for the long tail of small integrations that would never justify an engineering ticket. An engineered system is the right tool for the three or four processes that actually matter. The mistake we're called in to fix is almost always the same one: a process that started as a modest low-code scenario became load-bearing, and now nobody can explain what it does, who changed it last, or why it silently skipped two hundred records last quarter.
What Make is genuinely good at
Make's strength is time-to-first-working-thing. A business analyst who understands the process can build a functioning integration in an afternoon, see the data moving visually, and hand it to a colleague. The connector library is broad, the visual canvas makes simple branching legible to non-engineers, and there is no infrastructure to own.
That makes it a good fit for:
- Notifications and routing — a form submission creates a ticket, pings a channel, appends a row.
- Low-volume data movement between two systems that both have decent APIs.
- Prototyping a process you intend to formalize later, to learn the real edge cases before committing engineering time.
- Departmental work where the department owns the outcome and the blast radius of a failure is one team's afternoon.
Where it stops: error handling is workable but shallow, so a failed run in the middle of a multi-step scenario tends to leave your systems in a half-updated state that someone has to reconcile by hand. There is no real branching-and-merging development model, so two people improving the same scenario is a coordination problem solved by asking each other. Testing means running it against something. And the pricing model is per-operation, which means cost scales with the thing you are trying to increase — throughput. Teams routinely discover that the scenario that was cheap as a pilot is a line item once it handles the whole volume.
What n8n is genuinely good at
n8n sits in a useful middle position. It keeps the visual canvas, but you can drop into JavaScript or Python inside a node when the logic outgrows the UI, and you can self-host it inside your own network. That last point matters more than it sounds: for a lot of finance and healthcare workflows, the deciding factor is not features but whether data leaves your perimeter and which third party holds the credentials to your systems of record.
Self-hosted n8n also gives you the beginnings of real engineering discipline. Workflows can be exported as JSON and committed, which means you can diff them, review them, and promote them from a test instance to production instead of editing live. It is not the same as a codebase — the JSON is machine-shaped and a meaningful code review is hard — but it is a long way from clicking around in production.
Where it stops: self-hosting is a real operational commitment. Somebody owns upgrades, the database behind it, queue mode and worker scaling, backups, secret rotation, and the monitoring that tells you a workflow stopped firing at 3am. Teams that adopt n8n to avoid engineering cost are often surprised to find they have hired platform work instead. Complex workflows also become genuinely hard to read: past a few dozen nodes with nested branches, the canvas that made simple things clear makes complicated things opaque. And licensing terms around embedding and commercial use are worth reading closely before you build a customer-facing product on it.
What a custom build actually buys you
"Custom" does not mean writing everything from scratch. It means the automation is a versioned application: code in a repository, tests that run before deployment, a defined data model, structured logs, retries and idempotency designed for the specific failure modes of the systems involved, and access controls that map to your existing identity provider. Most of what we build for clients leans heavily on managed services and existing libraries — the custom part is the process logic and the guarantees around it, not reinventing a queue.
The things you get that low-code platforms struggle to provide:
- Correctness under partial failure. If step four fails after steps one through three committed changes, an engineered system knows how to make that safe — compensating actions, idempotency keys, a durable state machine that resumes rather than restarts. This is the single biggest difference and the one that surfaces only after go-live.
- Audit trails that satisfy an auditor. Not "the platform logged a run" but an immutable record of what decision was made, on what input, under which version of the rules, by which identity, and who approved the exception. If your process is in scope for SOX, HIPAA, or a regulator's exam, this is usually the reason you move off low-code.
- Versioning and change control. Pull requests, review, staged rollout, and a rollback that takes a minute. When the rules change mid-quarter, you can prove which records were processed under which version.
- Cost that scales with compute, not with steps. High-volume processes get cheaper per transaction as they grow, rather than more expensive.
- Judgment-heavy work. Anything involving document understanding, classification, or reasoning over unstructured inputs needs evaluation harnesses, confidence thresholds, and human-in-the-loop routing. That's engineering, not configuration. It's the core of our document and data intelligence work.
The cost is honest and worth stating: a custom build takes longer to first value, requires a real requirements conversation, and creates something that needs an owner. If nobody will own it, don't build it.
The ceilings, side by side
| Dimension | Make | n8n (self-hosted) | Custom build |
|---|---|---|---|
| Time to first working version | Fastest | Fast | Slowest |
| Volume headroom | Limited by per-operation billing | Limited by how well you run the infrastructure | Designed to the requirement |
| Partial-failure recovery | Manual reconciliation is common | Possible with effort; easy to get wrong | Designed in from the start |
| Audit evidence | Run history only | Run history plus whatever you log | Purpose-built, immutable, queryable |
| Version control and review | Effectively none | Workflow JSON in git; hard to review well | Standard software practice |
| Data residency and perimeter | Vendor-hosted | Your infrastructure | Your infrastructure and your controls |
| Who can change it | Anyone with access | Anyone with access, unless you add gates | Whoever passes review |
| Ongoing ownership burden | Low | Moderate to high | Moderate, but explicit and staffed |
When the answer is "don't automate this yet"
We turn down automation work regularly, and these are the reasons why. If the process is undocumented and three people each do it differently, automating it just encodes one person's version as policy — map it first. If the upstream data is unreliable, automation converts a slow manual process into a fast wrong one; fix the data or build validation as the first project instead. If the process is about to change because of a system migration, a reorganization, or a new regulation, wait for the change and automate the destination. If no single person owns the outcome, whatever you build will rot within two quarters.
And if the process runs a handful of times a month and takes a few minutes each time, the automation will cost more in attention than the manual work costs in time. Our value calculator is a rough way to sanity-check whether the volume and handling time justify anything at all before you argue about tools.
Migration paths that don't require a rewrite
Nobody should rip out a working low-code estate. The pattern that works is to treat platform scenarios as the discovery phase and migrate selectively, in this order:
- Inventory and triage. List every scenario, who owns it, what it touches, how often it runs, and what breaks if it stops. Most organizations find a meaningful share of scenarios are dead, duplicated, or superseded. Retire those first — it's free capacity.
- Classify by consequence, not complexity. The scenarios to migrate are the ones where a silent failure costs money, breaks a control, or misstates a number. A complicated scenario that only sends notifications can stay where it is.
- Extract the logic, not the layout. Before migrating, write down the actual business rules in plain language, including the exceptions people handle manually. The scenario is an artifact of the tool; the rules are the asset.
- Run both in parallel, comparing outputs. Shadow the new system against the old one on live data until the differences are explained. Every difference is either a bug in the new build or an undocumented behavior of the old one — both are worth knowing before cutover.
- Keep the platform for the edges. A custom core with low-code at the periphery for notifications, ad-hoc reports, and one-off departmental needs is a legitimate end state, not a compromise. It's what most of our process automation engagements end up looking like.
Migrating from Make to n8n is usually a rebuild, not a conversion — the node models differ enough that automated translation produces something you can't trust. Migrating from n8n to custom code is easier, because the code nodes you already wrote often encode the hard parts of the logic and can be lifted with their intent intact.
How to decide, concretely
Ask four questions about the specific process in front of you. What happens if it silently fails for a week — an inconvenience, or a number in a filing that's now wrong? Will an auditor, a regulator, or a customer ever ask you to prove what it did on a particular day? Does the volume make per-operation pricing look worse over time? And is there a named owner who will maintain it? Two or more uncomfortable answers and you're looking at an engineered build. Zero, and the low-code platform is the correct, cheaper choice — use it and move on.
Our approach to engagements starts by mapping the process and arguing about the tool last, because the requirements determine the answer and the answer is often less ambitious than the buyer expected.
If you're weighing a platform against a build for a specific process — or you already have a low-code estate that's grown past what it can safely carry — talk to us. A scoping conversation will usually tell you which of the three you need, and whether you need it yet.
Questions we get asked about this
No. Self-hosting is an advantage only if you have a reason to keep data and credentials inside your perimeter, and a team willing to run the infrastructure. If neither applies, Make's hosted model removes real operational work at no meaningful cost to you. Choose n8n for the control and the code nodes, not for the label.
When it becomes load-bearing without anyone deciding that it should. The warning signs are consistent: nobody can explain the full logic, changes are made directly in production, failures are discovered by downstream complaints rather than alerts, and the output feeds a report someone external sees. Any two of those together is a signal to formalize.
Yes, and it's often the smartest sequence. The platform version teaches you the real edge cases, the exception rate, and the volume — which are the three things that make a custom build expensive to specify from scratch. Document the rules as you learn them, and that documentation becomes the requirements for the build.
Compare total cost of ownership over the life of the process, not first-year license against first-year build. On the platform side, the drivers are operation volume, connector tiers, and the internal time spent reconciling failed runs. On the custom side, they are initial engineering, hosting, and ongoing maintenance. Platform cost tends to rise with success; build cost tends to fall per transaction.
It depends entirely on what your controls require, not on the tool's marketing. If you need immutable records of what decision was made under which version of the rules, segregation of duties on changes, and evidence you can hand an examiner, a custom build is usually the practical route. Self-hosted n8n can satisfy data residency requirements while still falling short on change control. Our <a href="/security/">security practices</a> page covers how we handle this.
No, and forcing one usually backfires. A single standard either over-engineers the small stuff or under-engineers the critical stuff. A better policy is a threshold: below a defined level of consequence and volume, teams self-serve on the platform; above it, the process goes through engineering review. Publish the threshold so people know which side they're on.
Partial failures and upstream changes. A step succeeds, the next one fails, and the systems are left inconsistent with no automatic recovery — so someone reconciles by hand, and often doesn't know they need to. The second cause is an API or form field changing shape upstream, which the scenario happily processes as empty or malformed data.
Usually a short process-mapping exercise rather than a long evaluation. Once you can state the volume, the consequence of silent failure, the audit requirements, and who will own it, the answer tends to be obvious. The lengthy part is agreeing on those facts internally, not choosing between tools.
Bring us the process you were reading this for
Confidential assessment led by senior engineers. No obligation.