Technical debt in RPA: what an automation estate costs to keep

An RPA estate is not a set of finished projects. It is a set of programs that depend on screens and systems somebody else controls, and every one of those dependencies is a maintenance obligation that arrives on a schedule nobody in the automation team sets.

Below: why RPA accumulates debt faster than ordinary software, where the maintenance hours actually go, the build decisions that halve them, and when to retire an automation.

The economics of an automation programme change shape somewhere between the fifth and the tenth process. Before that, capacity goes into building. After it, a growing share goes into keeping what already exists alive, and nobody planned for that share.

This is not a failure of the technology. It is a structural property of automating on top of systems you do not control.

It is also predictable, which means it can be priced. The programmes that hit a wall are not the ones that accumulated debt — every estate does — but the ones that accumulated it without a number attached, and then had to explain a slowdown they could not account for.

Why RPA accumulates debt faster

Ordinary software depends on interfaces designed to be depended on — an API has a version, a deprecation policy, and someone accountable for not breaking it. Screen automation depends on interfaces that were never meant to be a contract.

A field moves twenty pixels, a supplier ships a routine update, a login page adds a step: none of those is a defect in the system that changed, and all of them break the automation. The change arrives with no notice because there was no notice to give.

The consequence is that maintenance load is proportional to the number of external systems touched, not to the amount of logic written. A short automation spanning four systems is a heavier long-term commitment than a complex one spanning two.

Where the hours actually go

Three places, in roughly this order. Source system changes, which is the one everyone expects. Credential and access expiry, which is mundane and consumes more time than it should because it is usually discovered by a failure rather than a calendar.

And exception drift: the process itself changes, new cases appear, and the rules written two years ago no longer describe the work. This one is invisible on any technical dashboard because nothing is failing — the automation is confidently handling cases the business has quietly redefined.

A useful planning figure is two to three hours per automation per month, averaged across an estate. It is not evenly distributed: a few automations consume most of it, which is why measuring per automation rather than in aggregate is worth doing.

The build decisions that halve it

Prefer a service over a screen wherever one exists. Even a partial move — authentication and data retrieval through an interface, the remaining steps on screen — removes the most fragile parts.

Externalise every configuration value. Paths, thresholds, account codes, date windows. A change that requires editing and redeploying the automation will be delayed; one that requires editing a file will not.

Centralise shared steps. Login sequences and common lookups repeated across twelve automations mean twelve edits when the login changes. Written once, it means one.

Log what the automation saw, not only what it did. When a run fails six months later, the input that caused it is the thing nobody kept.

None of these four cost meaningfully more to do at build time. All four cost several times the original build to retrofit across an estate, which is why they are worth mandating as a standard before the estate exists rather than discovering as a remediation project afterwards.

The team that is not sized for it

The second structural problem is staffing. An automation programme is usually funded as a project with a delivery team, and maintenance has no equivalent line — it lands on whoever built the thing, alongside their next build.

The visible effect is that delivery slows without anyone deciding it should. The team is not less productive; it is spending a rising share of its week on an estate that grows every quarter while the headline capacity stays flat.

The arrangement that holds is a deliberate split — a portion of capacity reserved for the estate, protected from the build backlog, and reviewed as the estate grows. Naming it makes the cost visible, which is the point: an invisible maintenance load is one that never gets funded and never stops growing.

The inventory nobody has

Most estates past a certain size cannot answer basic questions: how many automations are running, which systems each depends on, who owns them, when each last ran successfully.

That inventory is the prerequisite for every decision that follows, and it is usually a day of work to assemble the first time. Without it, the effect of a planned system upgrade cannot be estimated, and the upgrade proceeds as a surprise.

Keeping it current is the easy part once it exists, provided it is generated from what is actually deployed rather than maintained by hand in a spreadsheet that drifts within a quarter.

The single most valuable column in it is the list of external systems each automation touches. Read the other way round, it answers the question that matters most in practice: when this system gets upgraded, what breaks?

When to retire an automation

Some should be. A process that runs twice a month, breaks every time the source system updates, and takes forty minutes to do by hand is costing more to keep than to abandon.

The calculation is straightforward once the inventory exists: maintenance hours over the past year against manual hours saved over the same period. A handful of automations in any mature estate lose that comparison.

Retiring them is politically harder than building them, because it reads as an admission that the original decision was wrong. It usually was not — the process changed underneath it, which is the normal outcome rather than the exceptional one.

What this means for the business case

A return calculated on build cost alone will be wrong by the second year. The honest version includes an annual maintenance line, and it makes some processes clearly not worth automating — which is a useful result rather than a disappointing one.

In Colombia and Mexico this matters more than in markets where labour cost is higher, because the manual baseline being replaced is cheaper. The margin between build-plus-maintain and do-it-by-hand is narrower, and it can only be evaluated with both numbers present.

The programmes that scale are the ones that priced maintenance in from the first process. The ones that stall are usually not disappointed by the technology — they are surprised by a cost they were never shown.

Where to start

With the inventory, then with the maintenance hours over the past twelve months per automation. Those two together identify what to fix, what to leave, and what to retire.

A process automation assessment covers the estate as well as the candidate processes, so an automation plan is sequenced against real running costs rather than build estimates alone.

Frequently asked questions

Why does RPA accumulate technical debt faster than other software?

Because it depends on interfaces never designed to be depended on. A moved field or a routine supplier update breaks the automation without being a defect, and arrives with no notice.

How much maintenance should be planned per automation?

Two to three hours per automation per month is a reasonable planning average across an estate, unevenly distributed — a few automations consume most of it.

Where do the maintenance hours actually go?

Source system changes, credential and access expiry, and exception drift as the process changes underneath rules written years earlier. The third is invisible because nothing is failing.

Which build decisions reduce maintenance most?

Using a service instead of a screen wherever one exists, externalising configuration values, centralising shared steps like logins, and logging the input the automation saw, not only what it did.

When should an automation be retired?

When maintenance hours over the past year exceed manual hours saved. A handful in any mature estate lose that comparison, usually because the process changed underneath them.

Does maintenance change the business case?

Yes. A return calculated on build cost alone is wrong by the second year, and the margin is narrower in Colombia and Mexico because the manual baseline being replaced costs less.