Automations do not break because whoever built them did a bad job. They break because they are made of decisions taken at one moment, on top of tools that change without telling you. That brittleness is not an execution fault — it is a property of the model. And it carries a fairly measurable annual price.
What it costs before it breaks
The 2026 ranges: automation agencies charge $2,000 to $8,000 per workflow, and $8,000 to $60,000+ for a multi-workflow build or a custom agent. Monthly support for two or three workflows runs about $1,000 to $3,500.
So far, an ordinary quote. The interesting part comes after.
What it costs the following year
Two numbers that are almost never in the proposal:
Integrations add 20% to 40% to the project cost. Not an optional extra — that is connecting the tools, which is exactly what you hired the work for.
Maintenance takes 15% to 25% of the build cost, every year. A $6,000 flow drags $900 to $1,500 annually just to keep doing what it did on day one.
And there is a third cost, never invoiced but definitely paid: small business owners spend 4 to 7 hours a week on software and systems maintenance. When a flow goes down, those hours come out of somebody — usually the owner, or the least technical person on the team, because they were the one available.
Why they break, exactly
Three causes, and none of them is negligence:
APIs change. A tool bumps a version, renames a field or retires an endpoint, and the flow goes quiet. Nobody warns you; you find out because something stopped arriving.
The logic expires. The flow encoded your process as it stood that Tuesday. You change a price, add a service, hire somebody who does it differently, and the branch that existed no longer describes your business.
The unplanned case. The most common cause and the least visible. The flow does not crash — it simply finds no branch to apply, and sits there waiting for a human who does not know they are up.
There is a precise way of putting it that circulates in the trade: integration brittleness is design debt, and like most debt, it compounds silently until the bill arrives.
The thousand-runs rule
Of everything I read preparing this piece, this is the most useful — and it comes from the automation industry itself:
If a flow will run more than a thousand times a month, or if your business would notice it failing within a day, it probably should not live in a no-code tool long term.
It is an honest rule because it works against the interest of whoever states it. And it cuts both ways: if your flow runs fifty times a month and you would not care about a failure until Friday, building it in Zapier or Make is the right call, and anything bigger is wasted money.
When an agency automation is the right answer
Worth saying plainly, because sneering at them has become fashionable:
- The process is stable: it has worked the same way for two years.
- It has few branches: if this, then that.
- Volume is low and predictable.
- If it goes down, you notice and do it by hand without drama.
- You want it running next week.
That is the ground where no-code shines, and nothing beats it there. Commissioning a custom build for that is expensive and slow for no reason.
And when it is not
When the thing you want to automate is your business, not one of its tasks.
A real business is neither stable nor simple. One client asks to move an appointment, add a service and bill it together. Another pays half now. A third wants the quote as a PDF and over WhatsApp. Each variant is another branch, and each branch is another quote, another month of waiting, and another 15–25% a year in maintenance.
There comes a point where the signal is obvious: the team spends more time maintaining the flows than the flows save. At that point the automation has stopped being a solution and become one more system to maintain.
The alternative is not “more flows”
It is changing who decides the steps. Instead of chaining the path in advance, you give an assistant access to your data through a defined set of functions, and it composes the path case by case. The unplanned stops being a failure and becomes normal operation.
It is not magic, and it has costs too — variable ones, worth looking at up front. I go through it with numbers and with its limits in what MCP is, and what it actually changes in your CRM.