n8n vs Make vs custom code
Where each one holds up in production, where it breaks, and the point at which we move logic into code.
We use all three. The choice depends less on features and more on who will maintain the workflow, how much volume it handles, and how strictly it needs to be tested.
Make
Fast to build and easy for non-engineers to read. It works well for low to moderate volume workflows owned by an operations team. It becomes harder to manage when logic branches heavily or when you need version control and review.
n8n
Self-hostable, with code nodes when you need them. We reach for it when data needs to stay inside the client’s infrastructure or when a workflow mixes visual steps with real logic. It rewards some engineering discipline around environments and credentials.
Custom code
A small service is the right answer when volume is high, when exact replay matters, or when the workflow is core enough to deserve tests. It costs more up front and needs an owner who can read it.
Pick the tool the eventual owner can maintain, not the one that demos fastest.
How we decide
- 01Who maintains it after launch?
- 02Expected volume and peak load.
- 03Does data need to stay in your environment?
- 04Does it need tests, review and replay?
It is common for one project to use more than one. A visual tool handles orchestration and notifications while a small service does the part that has to be exactly right.