What Is RPA: Robotic Process Automation, When Yes and When No

They'll sell you RPA as the universal solution for automating your company; this article tells you what the salesperson won't. RPA (Robotic Process Automation) is software that operates other systems through the screen, just like a human: it opens the application, clicks the buttons, types into the fields, and copies data from one place to another. There's no physical robot — it's a program that mimics a user. And that strength (it doesn't need the system to cooperate) is also its biggest weakness: anything that changes on the screen can break it.

How an RPA bot really works

An RPA bot is built by "recording" or programming the exact sequence a person performs today:

1. Open the management system and log in.
2. Locate elements on the screen: the "New invoice" button, the "Tax ID" field. It identifies them by their position, their text, or their internal identifier.
3. Execute the sequence: click, type, copy, paste, next record.
4. Repeat for every row in the batch, at machine speed and with no typos.

The key difference from an API integration: RPA enters through the front door (the visual interface, built for humans), while the API enters through the service door (a channel built for programs). If you're not clear on what an API is, start with what an API is and how to connect your systems — it's the context you need to decide well.

When RPA is the only option (and it's perfectly fine to use it)

There are scenarios where RPA isn't a patch but the right tool, because no service door exists:

• Old systems with no API: desktop software from the 90s/2000s, custom systems whose developer no longer exists, legacy ERPs with no integration licensing.
• Closed terminals and applications: corporate online banking, AS/400-style terminals, insurer or health-plan applications that exist only as a screen.
• Third-party portals you don't control: the government agency or corporate client portal where you have to enter data by hand no matter what, and that offers no other route.
• Temporary bridges: you need the automation now, and the formal integration will take months. A well-designed RPA bot buys time — as long as it's treated as transitional.

A real-world note: before accepting that "the system has no API," it's worth having someone technical verify it. More than once we've found that the system did have an integration path —a partial API, an accessible database, a scriptable export— that nobody had explored. We cover the alternatives in connecting legacy systems without an API.

How much RPA costs: licenses vs. custom bot

Reference numbers for LATAM in 2026, conservative:

Item	UiPath	Power Automate (Microsoft)	Custom bot (code)
Monthly license	~USD 400-1,400 per bot by type (attended/unattended)	~USD 150-215 per unattended bot	USD 0 (no license)
Implementation per process	USD 3,000-15,000 with an integrator	USD 2,000-10,000	USD 2,000-8,000 one-time project
Typical annual maintenance	15-30% of initial cost + licenses	15-30% + licenses	10-20% of initial cost
3-year total cost (1 process)	USD 20,000-60,000	USD 10,000-30,000	USD 3,000-12,000

The honest read of the table: commercial RPA platforms make sense for corporations that will automate dozens of processes and need centralized governance, auditing, and an army of managed bots. For an SMB that needs to automate 2 or 5 processes, perpetual licenses usually cost more than building custom bots — which can also be designed to use APIs where they exist and the screen only where there's no other way, the best of both worlds within a custom software project.

Got an RPA quote and not sure it's the right tool for your case? Book a 30-minute call and we'll give you a technical second opinion, no strings attached.

The part the salesperson won't tell you: why RPA bots break

This section is the reason for this article. RPA is structurally fragile because it depends on something it doesn't control: another system's screen.

• The interface changed, the bot died. A system update moves a button or renames a field, and the bot clicks in the wrong place or waits forever for something that no longer exists.
• The unexpected throws it off: a "new version available" popup, a session-expired notice, a screen that took 3 extra seconds to load. A human resolves these without thinking; the classic bot doesn't.
• It fails silently or, worse, fails halfway: it processes 200 records correctly and 30 wrong, and nobody finds out until a customer complains. That's why monitoring and alerts aren't optional.
• Maintenance isn't an extra, it's the main cost. The industry assumes that an RPA bot in production needs constant adjustments; budget between 15% and 30% of the implementation cost per year, every year.

None of this happens (or happens far less) with an API integration: the channel is designed for programs, it's stable across versions, and it warns you with clear errors when something goes wrong.

Signs that RPA is a patch and not the solution

If you recognize any of these, the real problem is something else:

1. The system you're "robotizing" is yours. If the bot operates the screen of your own software, what's missing is to build it an API or modernize it — the bot is a band-aid over your own technical debt.
2. You're about to chain several bots to move data between your core systems. That architecture collapses with the first screen change; what you're describing is an integration, not a robot. That's the fundamental difference between RPA and code-based programmatic automation.
3. The process has constant exceptions that require judgment. Classic RPA doesn't decide; there the right conversation is about AI automation, where a model interprets and the code executes.
4. License costs already exceed the cost of building the real integration. It happens sooner than it seems: do the math over 3 years, not 3 months.
5. Nobody monitors the bots. RPA without monitoring is a ghost employee that could have been making mistakes for weeks.

If you're going to do RPA anyway, do it like this

When RPA is the right tool —a closed system, no API, impossible to change— these practices separate a bot that works for years from one that dies in its first month:

• Stable identifiers over coordinates: have the bot find the "Tax ID" field by its internal name, not "the third box on the left." It survives more visual changes.
• Validation at the end of each batch: the bot must verify against the system that what it entered actually got entered, and report the exact count — processed, failed, pending.
• Alerts, not silence: any exception triggers an immediate notice to a responsible person, with a screenshot of the moment of failure to diagnose quickly.
• Human schedule and pace: running the bot in low-load windows and at a reasonable speed avoids both blocks and suspicion on third-party portals.
• A living process document: every rule the bot executes, written down and owned on the business side. When the rule changes, the change comes in there and not through a rushed patch.

The decision rule, in one line

If the system has an API, integrate via API. If it doesn't and you can't change it, RPA — with monitoring and a maintenance budget. If the system is yours, fix the system.

At Deepyze we apply that rule without dogma: we build API integrations when the door exists, custom bots when it doesn't, and management systems when the current software is the real problem. Always with a fixed, closed price before we start and a team in your time zone that maintains what it builds. Tell us which process you want to automate and within 24 hours you'll have a concrete proposal that tells you, honestly, which of the three paths fits your case.