The context
An SME whose business runs on jobs carried out at customer sites: technicians on the road, schedules that keep moving, job sheets to fill in on site and bring back to the office.
Before the project, all of it lived in spreadsheets, printouts and phone calls. Which works — up to a certain volume.
The challenge
The trap with this kind of software is designing for the person who buys it rather than the person who uses it.
The owner wants visibility: where the teams are, what has been done, what is left to invoice. The technician is standing up, in a badly lit plant room, with one hand free and sometimes no signal. If the tool takes longer than the paper it replaced, it will not be used — and business software the field works around produces no reliable data at all.
And it had to live with what was already there. The company already runs its business on a management system: its customers, contracts, technicians and job sheets have lived there for years. Replacing it was neither asked for, nor sensible, nor affordable. So the new tool had to install itself alongside, work on the same data, and never put what already runs at risk.
What we did
- An API plugged into the existing management system’s database. Customers, contracts, technicians and job sheets remain the property of the legacy system: we read them without ever altering their structure. What belongs to the new tool alone — leave, notifications, internal documents — lives in its own tables, next to the others.
- A strict rule on the shared database: no automatic schema changes. Every modification goes through a script that is written, reviewed and run by hand. On a database you do not own, automation is not a convenience, it is a risk.
- A mobile app for the technicians, with data entry designed for the field: short journeys, fields cut back to what is necessary, nothing that assumes a comfortable keyboard.
- Data entry that survives having no signal. The schedule, the job sheets and the readings are kept on the phone: the technician fills in a sheet in a basement, has it signed on the spot, and synchronisation catches up when the network comes back.
- An office tool, built around a calendar schedule, for the people assigning jobs and tracking what is left to invoice.
- Iterative delivery, in small increments rather than one switchover. Business software is never specified correctly on the first attempt: it is the first real usage that reveals what is missing and what will never be used.
The outcome
The software has been under continuous development since 2024 and remains actively evolving — which, for a business tool, is the best possible sign: you only keep investing in something that gets used. The legacy management system, meanwhile, has not moved.
This project illustrates two convictions. The first: on field software, the success criterion is not feature richness, it is adoption. A feature nobody fills in is worth nothing, however well its code is written.
The second: you almost never need to replace a company’s legacy system. Most of the time it is enough to add what it lacks, where its users need it — which costs a fraction of a replacement and puts nothing at risk.
Client covered by a confidentiality agreement
