Field Service Mobile App

Technicians were carrying paper job sheets and photographing completed work on their personal phones, then transcribing everything back at the depot at the end of the day. Jobs completed in the morning weren't visible to dispatch until evening, so the office was scheduling against a picture of the day that was hours old. Photographs went missing regularly. The contractor wanted job details, completion capture and photographs in one app, and the non-negotiable requirement was that it work with no connection for most of the day.

I was one of two mobile developers, and this was the first project where I led anything — I owned the offline architecture and reviewed the other developer's work, with a senior engineer from another team checking mine. There was a backend developer, a designer and a delivery manager on the project too. I did most of the field visits, which I volunteered for and which changed how I built it.

I owned the offline layer: the local database, the sync engine, the conflict handling, and the queue that holds completions and photographs until there's signal. I built the job list and job detail screens and the completion flow, including the photo capture with its compression and retry logic. I owned the release process on both stores once the delivery manager handed it over. I didn't build the API or the dispatch web application, and the designer owned all the visual work.

The decision everything else follows from is that the app writes locally first and syncs in the background, always, even when there's a connection. My first prototype tried to be online-first with an offline fallback, and the failure modes were awful — technicians would get a spinner, wait, then lose the entry. Writing local first meant building conflict resolution I'd hoped to avoid, and it made the app behave identically regardless of signal, which is what field staff needed. I chose Realm over a SQLite layer mainly because its change listeners fit how I wanted the screens to update. For photographs I compress on device before queueing, after discovering that a day of uncompressed photos on a 4G tether was costing the contractor real money.

Technicians work in basements, plant rooms and rural sites, so genuinely no signal for hours is the normal case, not an edge case. The devices are cheap ruggedised Androids with limited storage, which is what forced the photo compression and a retention policy for synced jobs. The backend API was designed before we started and I couldn't change it much, so a lot of the sync engine works around endpoints that assume an online client. There was also a hard date tied to the contractor's own client commitment, which meant cutting two features rather than moving it.

Dispatch now sees completions within a few minutes of a technician getting signal instead of at end of day, which is what they were paying for. End-of-day transcription — about forty minutes per technician — is gone entirely. Lost photographs went from a regular complaint to none reported in the first six months. The number I remember is from a field visit: one technician showed me twelve jobs queued from a day in a basement plant room that all synced correctly when he drove out, which was the moment I stopped worrying about it.

The other mobile developer built the timesheet and parts screens and found several bugs in my sync engine by using it in ways I hadn't imagined. The designer went on two field visits with me and redesigned the completion flow afterwards for one-handed use with gloves on, which I would not have thought of. Four technicians tested early builds and were direct about what was useless.