We understand your processes. We use AI where it's needed. We build the tools. And we stay.

Processes — understand how the work gets done

We come into your company and look at how the work really gets done: the spreadsheets passed from hand to hand, the paper doing the rounds between offices, the same data typed two or three times into programs that don’t talk to each other. We speak with the people who do the work, not just the people who direct it.

The problem is almost never the program: it’s the route the information takes to get there. That’s why the first deliverable is not a quote but an honest picture of your process: where time is lost, where the errors are born, what’s worth touching first — and what already works, and should be left alone.

AI and research — what can really be done

AI is not a product we sell you: it’s how we work, and it’s inside the tools we deliver. In the analysis we have it read documents, mail and archives, and we walk into the interviews already knowing what to ask: the picture forms in days instead of weeks, and people confirm or correct instead of telling the whole story from scratch.

In the systems we deliver it does the repetitive work: it extracts data from the documents you receive, checks automatically what used to be spot-checked, answers questions in plain language over your archives. Not a parlour assistant: components at work inside your system. And we use it to build too — more code written and verified in the same time, more automatic checks, less cost to you. The craft, understanding the process and deciding what to build, stays with us.

This is not a position we took yesterday. Since 2017 we have run one research project a year, with grant calls, reviewers and audited reporting; in 2021, before everyone was talking about it, we were applying computer vision to manual work at an assembly bench.

Development — design and build the tool

Once the process is understood, we decide what to automate and what to leave to people. Not everything should be automated: some decisions must stay with those who know how to make them, and a tool that presumes to replace them simply gets worked around. The design arrives in writing: what gets built, in what order, what you will see working first. You argue over a document, not over a promise.

We build on one of our platforms — when the work fits what our products already know how to do — or made to measure, when your process requires it. Either way the tool follows the process, not the other way round.

Delivery comes in pieces: we put the first useful part in people’s hands, watch it work on real data, and correct it. A system you can see working halfway through is worth more than a perfect one promised for next year — and misunderstandings surface while they are still cheap to fix.

The watch — stay and keep watching

A tool delivered and then left alone ages badly. That’s why the fourth step never ends: servers and virtual machines, backups, updates and security stay under our NOC, around the clock. We see the faults first, and often fix them before you notice.

The watch is a line of work in its own right, with written rules and a quarterly drill: we tell it in full on the managed security page.