Robotic process automation gets sold to mid-size companies as the quick win. A bot logs into the same screens your staff use and clicks through them the way a person would, only faster. For a stable, rules-based task inside a system nobody can change, that works fine.
The trouble starts when a process runs across several tools that keep changing, or needs a bit of judgment along the way. At that point custom process automation, built on APIs and your own data instead of the user interface, usually costs less over a year than keeping the bots alive.
I’m CTO at udata, a software development company with 50+ engineers that builds automation systems and internal tools for growing businesses. Below is how we decide which approach fits, and what a custom build actually involves.
What RPA Still Does Well
It would be unfair to write RPA off. Bots are a good answer when the target system is an old desktop application with no API and no vendor willing to add one. They also make sense for short-lived needs, like a migration that runs for two months and then disappears, or for a pilot where you want to prove that a process is worth automating at all before spending on a proper build.
Companies with strict change control like them for another reason. A bot doesn’t modify the underlying system, so it can get approved faster than an integration that writes to a production database.
If your situation looks like that, use the bot.
Where Bots Start Costing More Than They Save
The typical problems show up later, once the bot has moved from pilot to something people depend on:
- Screens change and bots break. A SaaS vendor moves a button or renames a field, and the bot fails, sometimes silently, sometimes at 2 a.m. before a reporting deadline.
- Exceptions land back on people. The bot handles the clean cases and pushes everything unusual into a queue. Someone still has to work that queue, and it rarely shrinks.
- Licensing grows with volume. Most RPA platforms charge per bot or per runtime, so success makes the bill bigger.
- The data stays trapped. A bot copies values from screen A to screen B. It doesn’t leave you with a clean database you can report from or feed into anything else.
- Unstructured input defeats it. Emails, scanned invoices and supplier PDFs in twenty layouts are where rule-based bots give up.
Usually the bot did its job. The process just grew past what screen-clicking can handle.
What Custom Automation Looks Like in Practice
A custom build skips the screens. It talks to your systems directly through their APIs, runs scheduled sync jobs, and keeps its own database so every record has a history. Exceptions don’t vanish into a bot log. They show up in a small internal tool or dashboard where a person can fix them in a few clicks, and the fix feeds back into the rules.
Our usual stack for this is plain on purpose: Python with FastAPI or Node.js on the backend, PostgreSQL for storage, Docker for deployment. Nothing exotic, which matters when the client’s own team has to live with it later.
Where input is messy, we add a language model. Pulling fields out of an invoice or classifying an inbound email is exactly the kind of task that used to require a person and now doesn’t. We route between OpenAI, Anthropic’s Claude and Google Gemini depending on cost and the task, and we keep a human review step anywhere money or contracts are involved. A misread supplier name is easy to fix; a wrongly approved payment is a lot less fun to explain.
A Food Producer’s Automation, Delivered in a Week
One of our cleaner examples is an operational automation system for a food-production business. We estimated $5,000 and three weeks of work. It closed at $3,000 in one week, built by a single full-stack developer.
The developer wasn’t unusually fast. The client arrived with the page structures mapped out, the workflows written down and a database schema already drafted. There was almost nothing to guess at, so almost nothing to rework.
I bring this case up in every automation conversation because it applies to RPA just as much. A bot automates whatever process you hand it, including the confusing parts. If the process lives in one operations manager’s head, both approaches get expensive.
How to Choose Between a Bot and a Custom Build
Before you renew a bot license or commission a build, answer these honestly:
- Does the target system have a usable API? If yes, a direct integration will almost always be more stable than clicking through its interface.
- How often do the screens or the process itself change? Monthly changes favor custom code. Changes once every few years favor a bot.
- What share of cases are exceptions? If your team already spends hours a week clearing a bot’s exception queue, that time belongs in the cost comparison.
- Do you need the data afterwards? Reporting, forecasting or AI features all need clean, stored data, which bots don’t produce.
- How long will the process exist? A one-off migration doesn’t justify a build. A core order-to-invoice flow you’ll run for years probably does.
Mixed answers are common, and mixed setups are perfectly reasonable: a bot can keep handling one legacy screen with no API while everything around it moves to direct integrations.
Start With the Process Map
Whichever way you lean, the first step is the same and costs nothing but time. Write the process down step by step: who touches it, which systems it passes through, what the exceptions are and how people handle them today. Once that document exists, the tool choice usually becomes obvious, and any quote you get becomes much more reliable.
That mapping step is also where most of our custom process automation projects begin, before anyone writes a line of code. Teams that skip it tend to pay for the same discovery later, at development rates.
About the author: Dmytro Serebrych is CTO and co-founder of udata, a software development company that builds custom software, process automation, data pipelines and AI systems for growing businesses in the US and Europe. Connect with him on LinkedIn.
