Automation proposals almost universally get the build cost right, or close enough. What they consistently miss is that shipping the automation isn't the finish line, it's the start of an ongoing obligation that costs real money every year the automation keeps running. Skip that line item and the ROI case looks better on the proposal and worse on every budget review for the next three years.
Why automation specifically has this problem
Regular software features, once built and stable, tend to keep working with relatively light maintenance unless the surrounding product changes. Automation is different because it almost always depends on external systems you don't control: a vendor's API, an upstream data source, a partner's export format. Any of those can change without warning, and when they do, the automation breaks silently or loudly, either way it needs someone to fix it.
This dependency on external systems is the core reason a flat 15 to 20 percent of build cost annually is a reasonable planning assumption for ongoing maintenance. It's not because the code itself degrades, code doesn't rot on its own, it's because the world around the code keeps moving and something eventually needs to catch up. McKinsey's research on automation programs echoes this: the technical build is rarely where realized value falls short of projected value, ongoing operational cost and drift are where the gap actually opens up over time.
The specific things that break
API version deprecations. Vendors sunset old API versions on their own timeline, often with 6 to 12 months notice buried in a changelog nobody on your team reads regularly. When the deprecation date hits, integrations built against the old version stop working, sometimes gradually as specific endpoints get pulled first.
Data format drift. A field that used to always be populated starts showing up empty. A date format changes from one convention to another. A CSV export adds a new column that shifts everything after it if your parser assumes fixed column positions. None of these are dramatic, all of them break automations that weren't built to tolerate the change.
Authentication and security policy changes. Token expiration policies tighten, a vendor moves to a new auth standard, IP allowlisting requirements get added. These changes are often driven by the vendor's own security posture, not anything you did, and they can lock an automation out entirely until someone updates the integration.
Volume growth outpacing original design. An automation built and tested against a few hundred records a day can behave very differently at ten thousand a day, rate limits get hit, processing time grows past acceptable windows, memory assumptions that worked fine at small scale start causing real problems.
Authentication changes deserve their own callout
Of the four failure categories, authentication and security policy changes are the ones most likely to break an automation with zero warning and full urgency, because they're often treated by the vendor as security-critical and rolled out faster than a typical deprecation cycle. OWASP's API security guidance covers the broader landscape of what's shifted in API authentication norms over the past several years, token rotation requirements, scope restrictions, stricter rate limiting tied to auth tier. None of it is arbitrary from the vendor's side, but from the automation's side it can mean a working integration stops authenticating overnight with an error message that doesn't obviously point to "your token policy changed."
Building in credential rotation handling and clear alerting on auth failures specifically, rather than lumping them in with generic errors, saves meaningful debugging time when this happens, and it will happen eventually on any automation that runs long enough.
Why teams underestimate this so consistently
Part of it is optimism bias, the automation working correctly on launch day feels like the hard part is over, and it's genuinely hard to picture the specific failure that hasn't happened yet. Part of it is that maintenance cost is diffuse, it's not one big number, it's a support ticket here, a half-day fix there, spread across a year in a way that never shows up as a single line item anyone questions.
The fix isn't heroic vigilance, it's structural. Budget the maintenance percentage upfront as a real line item, and set up monitoring that catches drift before it becomes a full outage, rather than relying on someone noticing the output looks wrong three weeks after it started. Gartner research on automation program failures consistently names underbudgeted maintenance as a top-three cause of initiatives that get quietly abandoned within two years of launch, not because the automation stopped working entirely, but because nobody was funded to keep fixing the small breaks as they accumulated.
What good monitoring actually catches early
A basic health check on any automation should verify three things on a regular cadence: the upstream source is still reachable and returning expected data shapes, the processing step is completing within its normal time window, and the output volume is within a reasonable range of historical norms. A sudden drop to zero records processed, or a spike to ten times normal volume, is almost always a sign something upstream changed, and catching that within hours instead of weeks is the difference between a quick fix and a genuine incident.
This doesn't require expensive tooling. A scheduled check that pings the upstream source, compares today's volume against a rolling average, and posts an alert somewhere someone will actually see it covers most of what matters. General-purpose monitoring platforms document this pattern well if you want a reference implementation rather than building the alerting logic from scratch.
The compounding cost of skipping this on multiple automations
The maintenance math gets more urgent, not less, as an organization automates more processes. Five automations at 15 to 20 percent of build cost each is a meaningful annual number, and if none of it was budgeted upfront, it shows up as a growing, unexplained maintenance burden on whichever team ends up owning these integrations. That team, often without the original context of why each automation was built the way it was, ends up firefighting drift issues on systems they didn't design, which is a worse position than if the maintenance cost had been planned and staffed for from the start.
137Foundry builds this kind of monitoring into automation projects from the start rather than as an afterthought, specifically because the maintenance cost of catching drift early is a fraction of the cost of discovering it after downstream reports have been quietly wrong for a month.
Budgeting it honestly changes the whole proposal
Once maintenance is a real, budgeted line item instead of an invisible future cost, the payback period calculation changes, sometimes meaningfully. A process that looked like it paid back in four months on a build-cost-only basis might actually pay back in six once realistic maintenance is included. That's not a reason to kill the project, a six-month payback is still often a strong case, it's a reason to present the honest number instead of the flattering one, because the honest number is the one that survives the first year of surprises instead of eroding trust in the next proposal.
For the full ROI framework, including how to structure the build-cost-versus-maintenance-cost tradeoff in the actual payback calculation, 137Foundry's guide to automation ROI walks through the math with worked examples.
Top comments (0)