Legacy desktop applications
PowerBuilder, native Windows, business applications without a test interface.
- Screen recognition by accessibility or image
- Version-resilient anchor
- Datasets and reset
Custom automation
Selenium, Cypress, and Playwright cover the web. Beyond that — rich client, PowerBuilder, ordering kiosk, production screen, business terminal — most service providers stop where the tool stops. We write what is missing.
Make an appointmentThe wall
This is the sentence heard by CIOs whose core business does not run in a browser.
An app PowerBuilder who has been driving production for twenty years. A heavy Windows client whose fields have no stable identifier. A kiosk whose embedded browser changes ports on every reboot. A production screen that exposes no interface. In all these cases, standard tooling fails to bite — and testing remains manual, thus partial, thus slow.
These systems have one thing in common: they are rarely the least critical. They are the applications that were never replaced because they work, and that are tested by hand because people think they have no choice.
What we do
PowerBuilder, native Windows, business applications without a test interface.
Control based on what is displayed, without installing anything on the client's machine.
When the interface is missing, we go look for the truth where it is: database, log, application interface, print stream.
The proof
We are not selling an intention: the workshop has already produced a complete automated machine for a fast-food chain.
He reads the campaign brief, enters the configuration into the POS system, reviews it to ensure it matches, operates the kiosk to check what the customer sees on the screen, and compares the points of sale with each other. 25,704 comparisons in one minute, where the same manual check took about seventy hours.
What he found on the first pass: four items from an ongoing campaign with no prices in a restaurant, so unsellable, the day before they were featured. No market tool could do that—because no one had written it.
How to get involved
Delivered to your warehouse, documented in French, with installation and update procedures.
Two to three weeks to prove that the pilot runs on your system. If it doesn't work, we'll tell you and we stop there.
On the operated equipment, no source code, no development tools: the binary, or nothing at all.
Frank questions
Because we first need to verify that it covers your use case. When that is the case, we say so and we use it—it's cheaper for you and faster for us. Custom development is only justified where standard tools fall short: heavy client apps, embedded equipment, proprietary protocols, closed systems.
Yes, provided one accepts that anchoring does not happen in the same way as on the web. We rely on accessibility layers when they exist, on visual recognition otherwise, and we stabilize the whole thing using controlled datasets. The first task is always a feasibility test on a real user journey, not a promise.
You, if you wish: the code belongs to you and is documented for that. Us, if you prefer, within a maintenance framework. What we refuse is the black box that no one else but us can open.
Two to three weeks for the feasibility trial, six to ten weeks for an initial live scope depending on interface complexity and environment access. Access is almost always the real delay, not development.
This is a question that must be asked before, not after. If a replacement is planned in the short term, we guide towards verification by data rather than by screen: it survives the interface change, whereas screen automation would have to be redone.
A no-obligation audit of your testing process to find out where you really stand.
Make an appointment
English 
French 
Hebrew