Python RPA services

Robotic process automation means driving software the way a person does: mouse clicks, keystrokes and UI elements. It is slower than an API call, it needs a machine to run on, and it needs maintaining whenever the screen it drives changes.

So it is the right answer for exactly one situation (a system with no way in) and the wrong answer for everything else. If a published connector or an API exists, that route is cheaper to build, cheaper to run and far more durable. See Power Automate services.

That is worth saying plainly because most of the RPA market is sold the other way round. A tool licensed per bot has an obvious interest in bots being the answer.

Microsoft's own answer to screen-driving is Power Automate Desktop, and this choice is made from having built with both. PAD is a low-code designer, and for common patterns it is fine. The trouble starts when a process stops being a common pattern: past a certain complexity you spend more time working around the tool than working with it, and some of what the process needs is not available in it at all.

Python has no ceiling of that kind. Whatever the process actually requires can be written, and the whole library ecosystem is there for the parts that are not really about clicking: parsing a file, reshaping data, reading a database, handling the cases that only turn up occasionally. That is the reason for the choice. The licensing is a consequence of it, not the argument for it: no per-bot licence, no Premium requirement, and readable code you own rather than a licence you rent, which a Python developer you hire later can maintain.

It also removes a conflict of interest. Both halves are built here, so there is nothing to gain by pushing your work onto the more expensive one. A supplier who sells only one cannot give you that answer.

What it does cost is worth budgeting for. There is a machine. Screen-driving needs somewhere to run, physical or virtual, and you own it and its uptime. And there is maintenance, because when the screen changes the automation needs attention; expect it after supplier updates. Connector work has neither problem, which is the honest argument for using connectors wherever they reach.

1. You record the process

   Unlike a cloud flow, which is built from an idea, screen-driving reproduces something a person is already doing, click for click. So it starts by capturing that. What we need is a screen recording of you doing the job once, talking through it: every step, every click, and what you are looking at when you decide something. Not a written spec. If it is easier on a call while we watch, that works too.

   The narration matters as much as the clicks. The parts you do without thinking are the parts that break an automation: the screen that has to finish loading before the next click lands, the field you tab past because it fills itself, the pop-up you dismiss so often you no longer see it, and what you do on the day the number looks wrong. A recording with no commentary shows the happy path, and the happy path is not where automations fail.

   One practical note: a screen recording shows whatever is on the screen. Record against a test record or a dummy case where you can; where you cannot, say so and we will agree how to handle it before you send anything. Ask how to send the recording.

2. The question is not whether it can be done

   If a person can click it, so can a script, so whether it is possible is rarely the answer you are waiting for. The open questions are the other ones.

   What will break? The recording is read against a written record of what has failed before: steps that depend on timing, steps that depend on where something sits on screen rather than what it is, the pop-up that only appears some days. That is where screen-driving fails, and it shows up in your recording before anything is built.

   What happens on the runs your recording does not show? Where it stops and asks for a person rather than carrying on regardless.

   Is it worth it? Whether the volume repays the machine it needs and the maintenance it will ask for, and whether a published connector reaches that system after all, in which case you are told so rather than sold a robot.

3. You approve the design

   You see what it will do before it exists, in plain language: which screens it touches, what it does when one of them does not look the way it expected, and where it stops and asks for a person instead of guessing. Any objection from the assessment comes with it, so you decide with them on the table.

   Changes at this point cost a conversation. Changes after the build cost the build.

4. It gets built, fast

   Development is AI-augmented too, working from the same framework that produced the design, so nothing is re-interpreted on the way in. The building blocks are already there and already proven, and yours starts from something that runs rather than from an empty file. Work normally quoted in weeks is usually delivered in days.

   Speed is not the interesting part. Every build is reviewed independently before it is deployed, by a pass that did not write it, against rules enforced automatically rather than remembered. In this work the expensive failure is a confident wrong answer, not a missing one, and reviewing your own work is exactly how a confident wrong answer survives.

5. It is deployed, tested, and yours

   It goes onto a machine you own (a desktop or a virtual machine) and runs against real conditions until it behaves. Then you test it on the cases you know are awkward, including the ones from your recording where something looked wrong, because the person who knows what right looks like is you.

   After that it is yours, and there is nothing to keep paying us. What it does cost to keep running is set out under what it costs to own.