System integration and BPM processes
We connect CRM, ERP, accounting, payments and SaaS platforms, and move long-running business processes into a BPM engine — without rebuilding the systems that already work.
- 01REST and SOAP APIs, webhooks, queues
- 02Apache Camel, Spring Integration
- 03BPMN processes (Flowable) embedded in an existing CRM
- 04Data migration and ETL
Most companies do not need another system. They need the systems they already have to start talking to each other — reliably, with error handling and a record of what happened.
What we do
- Application integration — CRM, ERP, accounting software, payment gateways, marketplaces, data-provider APIs. REST, SOAP, webhooks, files, queues.
- BPM processes — long, multi-step processes (customer activation, reacting to declining activity, confirmations, approvals) modelled in BPMN and run on the Flowable engine. Human tasks land where the team already works — in the existing admin panel, not in yet another tool.
- Data migration — moving data between systems with validation, a discrepancy report and the ability to re-run.
- Custom systems — where off-the-shelf software does not fit the process. We have been doing this since the 1990s, from production planning to cost estimation.
How we work
We start with a map of the data flow: which system is the source of truth, what happens when one side does not respond, how retries work. An integration without answers to those questions only works on good days.
Speed comes from not rebuilding the source systems. For example, a BPM engine embedded in an existing admin panel reached production in 4 days, and full integration with the UI took 7–9 days.
Related case studies
- Industry
- SaaS platform, automotive (US market)
- Timeline
- 7–9 days
- from first code to production
- 4 days
- full UI integration
- 7–9 days
A BPM engine embedded in an existing CRM — in 7–9 days
Long-running customer processes — activating new accounts, reacting to declining activity, collecting confirmations — moved from spreadsheets and sales reps' memory into a BPM engine. Without rebuilding the admin panel the team already worked in.
Read the case study
- Industry
- SaaS — automotive intelligence (US)
- environments — test, beta, canary, production
- 4
- automated tests in the modernised service
- 0 → 200+
Modernising a SaaS platform — from a decade-old application server to full DevOps
An automotive data platform for the US market ran on an application server more than a decade old and was built by hand. We moved it to a modern stack, built new interfaces for customers and staff, and a complete CI/CD process on our own Kubernetes cluster.
Read the case study
Related reading
2026-08-20
BPM tasks belong in your CRM, not in a separate panel
BPM engines ship with their own task lists and ready-made UIs. We embedded process tasks in the existing admin panel instead. Here is why — and what the first week after go-live taught us.
2026-10-14
The customer as a process participant — BPM tasks from an email link
Some process steps can only be completed by the customer — confirm, accept, reply. Here is how to bring the customer into a BPM process without exposing the process engine and without tokens in links.
Have systems that should be talking to each other?
Tell us which systems you want to connect and what should flow between them — CRM, ERP, accounting, payments, processes. We will assess the scope and propose the shortest path, without rebuilding what already works.