This is a decision framework, not a migration guide. It sets out the questions that decide whether a workflow belongs in a no-code tool or in code, and what a coded workflow has to provide to be worth the change. The failure-handling behaviour it describes can be inspected in the BullMQ task queue demo.
The trap. A workflow starts as one Zap: a new lead becomes a chat message. It is simple and it is cheap. Then a second one follows, then a lookup step, then a loop over a spreadsheet. Each addition is small, and the sum is a business process nobody can see end to end.
The cost is not only the subscription. It is the silent failure: a workflow that stops when a column header changes, and nobody finds out until a customer asks where their data went.
Three tiers, one question each
| Tier | Fits when | Failure visibility | Cost driver |
|---|---|---|---|
| Hosted no-code (Zapier and similar) | Validating whether a workflow is worth having at all | Limited to what the vendor exposes | Per task or per run, priced by the vendor |
| Self-hosted workflow tool | Branching logic that still benefits from a visual editor | Run logs, inspectable per step | Hosting plus whoever maintains it |
| Code (a small service or function) | Core customer data, transformations, proprietary APIs | Whatever the team builds: logs, retries, tests | Engineering time and ownership |
Pricing changes and differs by plan, so the table names the cost driver rather than a figure. Check the vendor's current execution model against the workflow's real volume before choosing.
Tier 1: hosted no-code is for validation
If it is not yet known whether a workflow is valuable, a hosted tool answers that in an afternoon. That is its job. Its limits show up when the workflow becomes important: error handling is whatever the vendor offers, a failed step can leave data in limbo, and a loop over many rows is billed as many runs.
Verdict: use it for non-critical convenience automations. Treat it cautiously when a workflow becomes a core customer-data pipeline; explicit failure handling and ownership matter more at that point.
Tier 2: a self-hosted workflow tool buys visibility
Self-hosted tools remove the per-run bill and expose each step's input and output, which is usually the point at which a team can finally see why something failed. The trade is that someone now owns a server, its upgrades, and its credentials.
Verdict: reasonable for branching operational workflows when the team has an owner for the host.
Tier 3: code is for anything that must not fail silently
Some workflows are really product logic: cleaning and normalising data, talking to a proprietary internal API, or moving records whose loss would be noticed by a customer. These need what a glue tool cannot give: explicit failure, retries with backoff, a place for jobs that keep failing, and a test that proves the transformation.
The task queue demo shows the reliability half of this tier: a failing job is retried with exponential backoff, then routed to a dead-letter queue instead of vanishing, and every attempt is visible in the worker telemetry. That is the bar a coded workflow should meet before it replaces a glue tool.
The signals that say it is time to move
- Cost: the automation bill no longer fits the value or the volume of the workflow.
- Latency: a run is too slow for the response time the process actually needs.
- Reliability: there are records that did not sync and nobody can say why.
- Ownership: the workflow matters, and no one can read it end to end.
When to stay put
- The workflow is a convenience, and a missed run costs nothing.
- A standard integration already handles the edge cases.
- There is no one to own a service after it is built. Code without an owner fails in the same silent way, just later.