Process automation without dependence on one platform
For process automation, you can choose a commercial RPA platform or a solution built from open-source and self-hosted tools. The difference is not only the licence price. It also matters where the robot runs, who owns its code, what support you need, and how much the infrastructure and maintenance cost.
Common problem: “no licence” is confused with “no cost”
A self-hosted solution can remove some commercial-platform fees, but it still needs a server, updates, monitoring, and someone who understands its operation. In addition, not every source-available tool has an open-source licence.
How we choose the robot’s foundation
Robot Framework records the robot’s process with keywords. With suitable names, it can be understandable even to a colleague without deep programming knowledge. It is text in your repository, not a schema locked inside someone else’s platform: you can see the change history, verify the process with test data, and produce a report of completed steps from a run.
n8n connects email, APIs, files, and databases in one workflow. Its source code is available, but the project does not describe itself as open source and uses the Sustainable Use License. Self-hosting is possible under the terms of this licence; for use outside them, an appropriate commercial licence needs to be verified. Data can remain in your infrastructure if the workflow does not call external services.
Why this matters
The difference is not just that you do not pay licence fees. It also lies in what you actually receive.
You reduce dependence on one vendor. The robot’s process is stored in your repository, and open components can be operated under their licences. For source-available tools that are not open source, such as n8n, the terms for the specific use need to be verified separately.
You control where the data is stored. We can host the solution in your infrastructure. During the design, we also check which external services and connectors process the data.
The process is readable and testable. In Robot Framework, it is described with keywords: you can see the change history and verify it before deployment rather than only in live operation.
The costs are more transparent. Some open-source frameworks do not charge based on the number of robots, but the required infrastructure, oversight, and maintenance grow with the scope.
How we prepare it
We build the robot using established practices: we handle exceptions and make sure that a portal change does not require the entire solution to be rewritten. We deploy it to your server or CI and schedule the run. We configure alerts according to the agreed rules and hand over documentation with the solution.
We apply the same approach to automated testing of web applications. Process automation is technically similar, but it has a different goal.
What an open and portable foundation gives you
A solution for which you know the licence terms, code ownership, and operating costs. Appropriately chosen components reduce dependence on a single platform and allow your team or another supplier to continue maintenance.
Next step
Tell us what you currently do manually. We will explain what such a robot would look like, how much it would cost to create, and how much it would cost to maintain—we will state both figures, not only the first.