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.
What we did
- A Django foundation carrying the schedule, jobs, customers and sheets.
- Data entry designed for the field: short journeys, fields cut back to what is necessary, nothing that assumes comfortable keyboard input.
- 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.
This project illustrates a simple conviction: 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.
Screenshots
Client covered by a confidentiality agreement