Build vs buy: when a few hundred lines of Python beat an RPA platform

The proposal on the table was to buy a low-code robotic-process-automation platform to automate a set of HR workflows. It is a familiar shape: a repetitive process, a vendor with a polished demo, and a licence that promises to make the problem disappear. I disagreed, made the call to build instead, wrote the automation in Python myself, and it avoided roughly NZD 294,000 a year. The decision and the delivery were both mine.

This is not an anti-vendor post. It is about asking one question before you sign anything, and being willing to own the answer: what does this work actually require?

What RPA really costs

Robotic process automation is a specific answer to a specific problem: automating interactions with systems that give you no better way in, typically by driving their user interface the way a person would. When there is genuinely no API, it earns its place.

The cost model is less visible than the licence. You pay per bot, you pay for the infrastructure to run the bots, and you pay in operational overhead, because UI-driven automation is brittle by nature. A layout change, a slow page, an unexpected dialog, and the bot breaks. Someone has to own that fragility. Add a couple of engineers to run and maintain the platform and the true annual cost is well beyond the sticker.

The question I asked

So I looked at the workflows themselves rather than the demo. I worked out exactly what they needed to do, and the answer was simple: read and write structured data in a back-office system on a schedule. Nothing about them required driving a screen. That mattered, because the system exposed a perfectly good API.

If the data is reachable through an API, paying for software that pretends to be a human clicking through a UI is solving a problem you do not have. I was confident enough in that analysis to put my name on the alternative and take responsibility for delivering it.

RPA is for when you have no API. The first question is therefore never “which RPA platform” — it is “is there an API?” If there is, the conversation is usually over.

What I built

I wrote the integration in Python against the system’s API. A few hundred lines: authenticate, pull the records that needed processing, apply the workflow logic, write the results back, do it on a schedule, make it idempotent so a re-run is safe, and log enough that a failure explains itself. I designed it, built it and owned it end to end.

It is not glamorous code. It is the opposite of glamorous, which is the point. It does one job, it does it the same way every time, and when it breaks it breaks loudly and specifically rather than silently mis-clicking through a screen.

Total cost of ownership, honestly compared

Set the two side by side.

The platform: per-bot licences, dedicated infrastructure to run them, and the headcount to maintain a fleet of brittle UI automations. Recurring, growing, and mostly opaque until you are locked in.

The integration I built: the engineering time to write it, and modest ongoing maintenance against a stable API. That was the difference that added up to about NZD 294,000 a year in avoided licences, infrastructure and hires.

When I would buy instead

I own the build call, but build is not always right, and I would say so:

There is no API, and the only way in is the UI. That is exactly what RPA is for.
Non-engineers must own and change the automation. A low-code platform they can maintain can beat elegant code that only one team understands.
You need vendor support, certification or a paper trail that an internal script will not give you.

The decision is not “code good, platform bad”. It is matching the tool to the actual requirement, and being accountable for the choice either way.

The lesson

The expensive default is to treat automation as something you procure. Sometimes it is. But a lot of “we need a platform for this” turns out to be “we need to move some structured data between two systems on a schedule”, and that is a scripting job with a maintenance cost measured in hours, not a licence measured in hundreds of thousands.

Look at the requirement before the catalogue, and be willing to own the smaller answer. When the requirement is small and there is an API, the smallest thing that works is usually the right thing, and the savings are real money.

This is one of the selected career impact stories on my home page. More engineering work, including tiaki, is on GitHub.