When the Workflow Should Be Software, Not Seven Tools
The same workflow built as a seven-tool chain and as one script: we measured config files, credentials, logs and what each tells you when something fails.
A workflow should become software when the cost of owning the chain — not running it — exceeds the cost of owning one small program. Running is cheap either way: a chain of tools executes in milliseconds and so does a script, and neither shows up on a customer invoice. Owning is where the two diverge, and four signals move first: how many times the payload is handed between systems, how often a run needs a human, how long it takes to answer "did the customer actually get notified," and who gets paged when it breaks at 5pm. If you cannot answer those four in five minutes today, you do not have an automation problem — you have a chain that quietly became software nobody wrote down.
We built the same workflow twice
So we did that. One workflow, seven steps: a lead arrives, gets validated, deduplicated, enriched, scored, written to a CRM, notified to sales, and logged. We built it two ways.
The first version is a chain of seven standalone services. Each one has its own config file, its own credential, its own log, and passes JSON to the next one over HTTP. That is the shape every cross-vendor chain has — a form tool, an enrichment API, a CRM, a messaging gateway — whatever the logos on your stack diagram say.
The second version is one script: one config file, one log, one credential store, zero handoffs between systems. Same inputs, same outputs, same fault injected in the same place.
One honesty note before the numbers: this is a model of a chain, not a benchmark of any specific platform. A single Make scenario keeps its steps in one run history, and that genuinely helps — until the workflow spans four vendors, at which point the run history fragments along vendor lines anyway. "Seven tools" means seven logins, and seven logins do not share a log.
What the chain costs before anything breaks
| What you own | Seven-tool chain | One script |
|---|---|---|
| Config files to read before you can explain the flow | 7 (147 lines) | 1 (9 lines) |
| Credentials to issue, scope and rotate | 13 | 1 |
| Processes that must be running | 7 | 1 |
| Handoffs per run — each one a serialization and a re-send | 6 | 0 |
| Log files a single run touches | 7 | 1 |
None of those numbers appear on an invoice. They appear as onboarding time, as rotation day, as the sentence "ask Diego, he built it" — and Diego left in March.
The number people ask for first is speed: over 100 runs, the chain's median was 20.5ms against 0.7ms for the script. It is also the number that matters least. Nobody's customer can tell 20 milliseconds from 0.7. We measured it only to show that the chain buys nothing at runtime — the entire difference lives in ownership.
This is the half of the bill we already documented from the other side: the integration tax that adds 40% to 70% to a disconnected stack, and the per-task cost trap that shows up as an invoice. Those are the visible costs. The table above is the invisible one.
When it broke, the chain blamed the wrong tool
We cut the CRM step off mid-run and watched what each version told the caller.
The script returned 500 service_unavailable and named crm — the step that actually failed. One log file, one line, the answer.
The chain returned 502 and named validate — the first step in the chain, which had done nothing wrong at all. The real error was four hops away in a different service's log. Finding it meant opening the five log files that recorded that run and looking for the one that was not "ok."
That is not an accident of our harness; it is what handoffs do. Each system that receives a failure from downstream reports it as its own failure to the system upstream, so by the time the error reaches the person who triggered it, it names the edge you touched rather than the step that broke. In a chain, the error message describes where you were standing, not what went wrong.
In fairness: the script did not escape the partial write either. Both versions left the dedupe marker written and no CRM record behind — neither is transactional by default, and pretending otherwise is how teams pick the wrong tool. The difference is not what went wrong. It is how long it takes to find out: one log naming the right step, or five logs and an error that names the wrong one.
One change, three places to remember
We asked for a small change: store the phone number on the CRM record and include it in the sales notification.
The chain needed three config files touched — the validator's allowlist, the CRM's field map, the notifier's payload — plus three services restarted. The script needed two files and no restarts. Both were verified working afterward, phone reaching the notification in each.
Then we broke it on purpose: we updated the CRM and the notifier and left the validator's allowlist alone. Both versions accepted the change, returned 200, and wrote phone: null into the record and the notification. Silent, identical, no error anywhere.
That symmetry is the honest part — a partial change bites every architecture, and any article claiming otherwise is selling something. What differs is the distance between the two settings that must agree. In the chain, the allowlist and the field map live in different files owned by different services: you can update one and never open the other. In the script, they are three lines apart in the same file. The mistake is the same size. The chance of making it is not.
When the chain is still the right answer
The chain wins, and it is not close, in these situations:
- Different people own different steps. The person who edits the notifier should not be able to touch CRM logic. Separate configs are a permission model.
- The workflow still changes shape. New tool every quarter? Rewriting software each time is a worse trade than owning the chain.
- Volume is low and nobody will ever ask what happened to run #4,821. Reconciliation time is a non-problem below a certain volume.
- Nobody will own a program six months from now. Unowned software rots faster than an unowned chain, because at least the chain's vendor still maintains its half.
The chain is a loan: you trade ownership cost for speed of change. The loan is fine right up until the workflow stops changing and starts being relied upon — which is the moment most teams discover it, usually during an incident.
The four signals, in the order they fail
| Signal | How to measure it this week | What pushes toward software |
|---|---|---|
| Handoff count | Count how many times the payload crosses a system boundary in one run | More than three or four, or more than two vendors — every crossing is a credential, a serialization, a place the payload gets silently reshaped |
| Exception rate | Count runs that needed a human last week | If the number lives in someone's head instead of a report, the chain is already harder to own than it looks |
| Reconciliation time | Time yourself answering "did this customer actually get notified?" for one real case | Longer than a single log view — diagnosis cost scales with how many systems hold a piece of the state |
| Failure ownership | Ask who is paged when this breaks at 5pm | A shrug, a departed colleague, or "whoever built the zap" — nobody owns a seam |
Measure them in that order. Handoff count takes an afternoon and predicts the other three. Ownership fails last and costs the most, because by then the workflow is load-bearing and the person who understood it is not answering email.
Our stance
Keep the chain while the workflow is still changing shape. Convert it to software the first time you catch yourself explaining the flow from memory instead of reading it — that is the moment the chain has become undocumented software, and the only thing keeping it alive is that nobody has left yet.
Start with the measurement, not the rewrite: map the handoffs, time one diagnosis, name an owner per step. If the four numbers come back benign, keep the chain and stop worrying — our automation and chatbots work begins with exactly that audit, and only then does the build-vs-chain conversation make sense. Still choosing the platform itself? Make vs n8n vs Zapier is the comparison underneath this one, and AI workflow, custom app or SaaS is the wider decision that contains it.
Frequently Asked Questions
When should a workflow stay a chain of tools?
While the workflow is still changing shape. If you add or swap a tool every quarter, rewriting software each time is a worse trade than owning the chain. Keep it as tools until the flow stabilizes and people start relying on it daily.
How many tools are too many for one workflow?
There is no clean number, but three signals age badly: more than three or four handoffs per run, more than two vendors involved, and more than one person needed to explain how the flow works. Any two of those together means the chain is already carrying software's weight without software's advantages.
Isn't a script harder to maintain than a visual builder?
A script is harder to change if nobody owns it, and easier to change if someone does. The real comparison is not visual versus code — it is one file one person can read versus seven configuration files that must agree with each other. Maintenance cost tracks how many places have to change together, not how the change is made.
