Case study
A commercial HVAC and refrigeration contractor was dispatching roughly sixty technicians on paper every morning. We built an Android app that works with no signal at all, and a dispatch web app that shows every job as it changes.
Named only with client approval Figures marked are illustrative Reply within one business day
Good morning
Your account at a glance
Balance
12,480
OlDevs built an offline-first Android app and a web dispatch back office for a commercial HVAC and refrigeration contractor running roughly sixty field technicians across southern Ontario.Technicians open a work order, capture photos, parts used and a customer signature with no connection at all, and the phone uploads the work whenever it finds a network again. Dispatch schedules jobs, watches status change through the day and pushes changes to the field from a Node and PostgreSQL web app, with edit conflicts resolved on the server instead of handed back to the technician. The five month engagement reported a +22% First-time fix rate, a 64% reduction in Job close to invoice and 60 Technicians on the app.
Key facts
The challenge
Work orders left the office on paper and came back days after the job was done, often missing parts lines or a customer signature. Dispatch ran on phone calls, so a job that had gone long was only discovered when the next customer rang to ask where the technician was. Half the sites were mechanical rooms and rural properties with no signal, which ruled out anything that needed a live connection to work.
Parts lines and customer signatures were missing often enough that the office had to chase them. The gap was found days after the technician had left the property, so closing a job meant phone calls, guesswork or a second visit to get a signature.
Scheduling and reassignment happened over the phone, one call at a time. Nobody in the office knew a job had run long until the next customer called to ask where the technician was, and there was no record of when anything actually started or finished.
Mechanical rooms, basements and rural properties had no usable connection. Any tool that expected a live network would have failed exactly where technicians spend the day, so a live-only system was never going to survive contact with the route.
Billing could not start until the paper came back, was read and was checked for a signature. That put the invoice behind the work, tied up cash, and made disputes harder to settle because the evidence from the job was not attached to it.
What we built
We built an Android app in Kotlin and Jetpack Compose backed by a local Room database and WorkManager sync, so a technician can open a work order, capture photos, parts used and a customer signature entirely offline and have it upload whenever the phone finds a connection again. The back office is a web app on Node and PostgreSQL where dispatch schedules jobs, watches status change through the day and sends changes out to the field. Conflicts from two people editing the same job offline are resolved on the server, so nobody in a mechanical room is asked to decide which version wins.
Kotlin and Jetpack Compose with a Room database as the source of truth on the device. Every screen reads and writes locally, so the app behaves identically in a basement and in the parking lot, and WorkManager retries the upload in the background.
Technicians attach photos, record parts used against the work order and take a customer signature on the phone before leaving the property. The completed record carries its own evidence, so the office is no longer reconstructing a job from memory.
A Node and PostgreSQL web app where the office builds the schedule, watches jobs move from assigned to on site to complete, and sends reassignments out to the field. Status arrives as phones sync rather than as a phone call at the end of the day.
When two people edit the same job while offline, the server applies the merge rules and keeps a record of what changed. Technicians are never shown a merge prompt in the field, and dispatch can see exactly how a job reached its current state.
Process
Following one work order end to end
Before writing code we traced a single paper work order from the morning print run through the job to the invoice, with dispatch and the service office, to find where it actually stalled.
Offline data model and sync contract
We agreed what a work order is, which fields a technician can change offline and how the server settles a conflict, then wrote that down as a contract both the app and the back office build against.
A working demo every week
Each week we put a build in front of the service manager and technicians, with the phone in airplane mode for part of the demo so offline behaviour was reviewed as a feature, not an edge case.
Tested where the signal is not
Sync, conflict handling, photo capture and signatures were exercised against the conditions the app had to survive: mechanical rooms, basements and rural properties with no usable connection.
Rollout and handover
We moved all sixty technicians onto the app, retired the morning print run, and handed over the code, the database, the deployment pipeline and the app store account in full.
Stack
Android app
Back office and API
Delivery and handover
Quality and monitoring
+22%
First-time fix rate
−64%
Job close to invoice
60
Technicians on the app
Outcomes
The morning print run stopped. 60 Technicians now open the day's work on the phone, and the completed record with photos, parts and a signature exists before they drive away from the site.
With the job history, past photos and parts detail available offline on the phone, technicians arrived better prepared. The client reported a +22% First-time fix rate.
Billing starts from a complete signed record that syncs the same day, which the client reported as a 64% reduction in Job close to invoice instead of waiting for paper to come back to the office.
The office watches jobs move through their statuses rather than phoning around for updates, so a job running long is spotted while there is still time to warn the next customer or move the work.
In their words
Our technicians stopped carrying paper, and the invoice goes out the same day the job closes instead of the following week.
Service manager, mechanical contracting firm
Field service and mechanical trades
FAQ
Yes. The device holds a local Room database that every screen reads and writes, so opening a work order, adding photos, recording parts and taking a signature all happen without a network. WorkManager uploads the work in the background once a connection appears, and the technician does not have to remember to sync.
The server settles it. Each device sends what changed rather than a whole record, the server applies the agreed merge rules and keeps a history of the result. Technicians are never shown a merge prompt in a mechanical room, and dispatch can see how a job arrived at its current state.
In most cases yes. Completed work orders, parts used and signatures live in PostgreSQL behind a documented API, so they can be handed to an accounting or ERP system rather than rekeyed. What that takes depends on what your system accepts, so we look at it during discovery and agree the integration before the build starts.
You do. Clients own all code, designs, accounts and IP, including the repository, the database, the deployment pipeline and the app store account. Nothing is held back, and another team could pick the project up from the handover documentation if you decide to take it in house at any point.
OlDevs is based in Vancouver, British Columbia and serves clients elsewhere remotely, with video calls scheduled in your time zone and on-site visits when the work calls for it. Offline behaviour is one of the things worth seeing in person, so a project like this one gets site visits rather than being designed entirely from a desk.
Let’s connect
Tell us what is not working. We’ll reply within one business day with how we would approach it and a tailored quote.