Workflow tools like n8n are excellent for connecting systems quickly. Custom code is better when logic, scale or ownership demands it. Neither is always right, and plenty of good solutions use both. These are the questions we ask.
How linear is the logic?
A trigger, a few steps and a handful of integrations suits a workflow tool well. Deeply nested branching, loops with state, or heavy data transformation gets painful on a canvas and is easier to read, test and review as code.
Who will maintain it?
If someone non-technical needs to adjust it, a visual workflow is a real advantage. If it will live inside an engineering team's normal process, code with version control and code review is usually easier to keep healthy.
How much volume and how much failure can you tolerate?
High throughput, strict latency needs or strong guarantees about retries and ordering point towards code and proper queues. Low volume with occasional human follow-up is a comfortable fit for a workflow tool.
Does it need real tests?
Business-critical logic deserves automated tests and a deployment pipeline. That is straightforward in code and awkward on a canvas.
What does it cost over time?
Consider hosting, licensing and the cost of the next person understanding it. A quick workflow that nobody can safely change is not cheap.
The hybrid that often works
Let the workflow tool own the connections and scheduling, and call a small piece of custom code for the part that is genuinely complex. You get speed where it helps and testability where it matters.
We also keep a library of existing workflow patterns to start from, which can shorten the first version. Whether we adapt one or build fresh, the decision follows the same questions.