n8n vs Make vs custom Python
Use Make when you want a visual builder, prebuilt connectors, and no infrastructure to run. Use n8n when you want the same visual approach but self-hosted, with the option to drop into code for the awkward steps. Use custom Python when the logic, volume, testing, or error handling has outgrown what a workflow canvas expresses clearly.
The options
Make
Hosted visual automation with a large connector library and per-operation pricing.
- Non-engineers building and maintaining their own workflows.
- Connecting popular SaaS tools that already have connectors.
- Getting something running today with no infrastructure decisions.
- Moderate volume where per-operation cost stays reasonable.
- Per-operation pricing at your volume becomes a serious line item.
- The workflow has branching that makes the canvas unreadable.
- You need version control, code review, or a real test suite.
- Data residency rules mean the data cannot go through a hosted third party.
n8n
Source-available workflow automation, self-hostable, with the ability to write code inside a node.
- Teams that want a visual tool but need to self-host.
- Workflows that are mostly connectors with two or three awkward custom steps.
- Avoiding per-operation pricing at higher volumes.
- Keeping data inside your own infrastructure.
- Nobody wants to operate, upgrade, and back up another service.
- Most of the workflow ends up as code nodes, which means you have chosen the wrong tool.
- You need the connector breadth that the hosted commercial tools have.
Custom Python
Code in your repository, deployed to your cloud, with tests, version control, and real error handling.
- Complex branching logic that a canvas obscures rather than clarifies.
- Anything needing a test suite or a code review before it changes.
- High volume where per-operation pricing is untenable.
- Proper retries, idempotency, and diagnosable failures.
- Processing files and documents in ways visual tools handle badly.
- A visual tool genuinely covers it and non-engineers will maintain it.
- The workflow changes weekly and code review would slow that down.
- It is one small integration and there is no engineering capacity.
How to decide
| If this is true | Pick |
|---|---|
| A non-engineer will own and edit it | Make, or n8n if self-hosted |
| Data cannot leave your infrastructure | n8n or custom Python |
| The canvas has become unreadable | Custom Python |
| You need tests before a change ships | Custom Python |
| Half the nodes are already code nodes | Custom Python. You are most of the way there |
What we actually think
The visual tools are genuinely good and we recommend them regularly. The trap is the workflow that grows from six nodes to sixty over a year, where nobody can now say what it does and one wrong drag breaks it silently. Watch for the point where the diagram stops being clearer than the code would be.
Common questions
Can we mix them?
Yes, and it is a good pattern. Keep the visual tool for the connector-heavy parts and call a small Python service for the step that needs real logic. You get the maintainability of the canvas and the correctness of code where it matters.
Is self-hosting n8n much work?
It is a service to run: upgrades, backups, monitoring, and the database behind it. Not difficult, but it is not zero, and it should be a deliberate choice rather than a side effect of avoiding a subscription.
When is the right moment to rewrite in Python?
When a change breaks something unrelated, when nobody can explain what the workflow does, when the bill outgrows the value, or when a failure cannot be diagnosed. Any one of those is enough.
Still not sure which fits your case?
Describe the workflow and the constraints. You will get a straight recommendation, including the one where you do not hire us.