RPA vs custom software: when the robot is right and when it's a patch

RPA — robotic process automation — does one very specific thing: a program drives another program's interface as if it were a person. Opens the screen, clicks the field, types, tabs, hits save.

It sounds like a trick, and it is one. But it's a legitimate trick, and there are situations where it's exactly right.

When RPA is the correct answer

When the system has no other door. Software from 2006 with no API, no accessible database, no export. The vendor is gone, or charges a fortune for any change. RPA is literally the only way to get data in or out without replacing the system.

When the lifespan is short and known. You're migrating that ERP in ten months and until then a manual process has to be held together. Building a serious integration for something that switches off next year makes no sense; a robot that survives ten months does.

When the volume doesn't justify a project. Forty records a week. Automating it properly costs more than it saves. A robot built in three days pays for itself even if it breaks occasionally.

When you need to prove the project is worth funding. Sometimes the only way to get budget is to show the process working. A robot as a proof of concept is a perfectly valid political tool.

Why it's fragile by design

Everything that makes RPA easy is the same thing that makes it fragile: it depends on the screen not changing.

• The vendor moves a button in an update and the robot breaks.
• An unexpected dialog — "your password expires in 5 days" — and the robot waits forever.
• The system takes two seconds longer than usual and the robot types into a field that doesn't exist yet.
• Somebody leaves a session open on that machine and the robot does its work on top of it.

And there's a more serious problem than fragility: the robot validates nothing. It copies. If the source data is wrong, it replicates the error faster and more consistently than a human, who might at least have noticed an amount with an extra zero.

Then comes the cost nobody projects: every robot needs maintenance each time one of the systems it touches changes. With three robots that's manageable. With thirty, you have a whole team maintaining robots — which is exactly the manual work you set out to eliminate, only now with licence fees attached.

When it's worth building properly

Do the real integration when any of these hold:

• The process is core and isn't going away. If it still matters in three years, the robot is technical debt accruing interest.
• You need to validate, not just copy. The moment rules appear — "if the amount exceeds X, require approval" — RPA gets awkward and code gets natural.
• Volume is growing. A robot is linear: twice the records is twice the screen time. An integration handles a thousand or a hundred thousand without changing.
• You need traceability. Who changed what, when and why. A robot leaves, at best, a log of clicks.
• The systems do have APIs. If the door exists, climbing through the window is a hard decision to defend.

What AI changed

The break-even point moved, and moved a lot.

A good share of RPA existed because building an integration was expensive. That cost dropped substantially: what was eight weeks of development is two. Under the new arithmetic, many cases that justified a robot three years ago now justify doing it properly.

At the same time, AI gives RPA a capability it never had: understanding unstructured content. A robot that also reads the email, works out what's being asked and decides where it goes is far more useful than one that only repeats clicks.

Our read: RPA is fine as a tactical bridge with an explicit expiry date. If the robot has no shutdown date, it isn't a bridge — it's your company's architecture, and nobody chose it.

A practical rule

Before standing up a robot, write down the answers to three questions:

1. When do we switch it off, and what replaces it?
2. Who fixes it the day it breaks? (Because it will.)
3. What happens if it copies a hundred records wrong before anyone notices?

If all three have answers, go ahead — it's a good tool. If any doesn't, what you're about to build isn't an automation but a future problem with excellent presentation.

Not sure which side your case falls on? That's exactly the kind of thing a short diagnosis settles.