Workflow automation tools such as n8n, Zapier, or Make are genuinely useful — and genuinely limited. Knowing which side of that line a project falls on early avoids two expensive mistakes: building custom software for something a workflow tool would have solved in a day, or trying to force a workflow tool to become a product it was never designed to be.
Signs a workflow tool is the right choice
- The logic is a sequence of steps between existing systems with well-defined APIs.
- Volume and concurrency are moderate, and occasional delays of seconds are acceptable.
- The people maintaining it are comfortable working in a visual workflow editor rather than a codebase.
- There is no need for a custom user interface — the workflow runs in the background.
- Requirements are likely to change moderately, and a visual tool makes those changes fast to apply.
A workflow tool in these conditions can go from idea to running automation in days, with a much lower ongoing maintenance burden than a bespoke service.
Signs custom software is necessary
- The system needs its own user interface — for customers, staff, or partners — rather than running invisibly between other systems.
- Throughput, latency, or reliability requirements exceed what a general-purpose workflow engine is built for.
- The business logic is complex enough that a visual editor becomes harder to reason about than code: deep conditional branching, custom validation, or non-trivial state management.
- The system must integrate tightly with a proprietary data model, or needs test coverage, versioning, and code review as part of a formal release process.
- The workflow needs to evolve into a product with its own roadmap, not a one-off automation.
The middle ground
Many real systems combine both: a workflow tool orchestrating routine integration tasks (notifications, data syncing, simple approvals), calling into a custom service for the parts that need real business logic, validation, or a proper interface. This is often the most pragmatic architecture — it avoids reinventing generic integration plumbing in code, while keeping the parts that actually differentiate the business in a maintainable, testable codebase.
A workflow tool handling a process that has quietly become business-critical, with nobody reviewing its error rate, is a common source of silent failures. If a workflow starts carrying real operational weight, it deserves the same monitoring and ownership as any production system — regardless of which tool runs it.
A simple test
Before choosing either path, write down what happens when the process fails at 2 a.m. with nobody watching. If the answer is acceptable with a workflow tool's built-in retry and error notifications, that is a strong signal it is the right tool. If the answer requires custom recovery logic, audit trails, or a guaranteed response time, plan for custom software from the start.