Field survey app for a utilities contractor

Inspection crews recorded meter and line surveys on paper forms and typed them up at the end of the day, which meant a full day's lag, transcription errors, and photographs that arrived separately and got matched up by hand. About half the sites they visit have no usable mobile signal, which is why every previous attempt at an app had failed — the crews tried them, lost data at a site with no bars, and went back to paper permanently. The contractor needed the data captured at the site and the crews to actually trust it.

Mobile developer on a team of three, my first project where I owned a whole area rather than tickets. I built the offline capture and sync; a senior engineer reviewed everything and rescued me twice.

I owned the offline data layer — the local database, the queue of pending records, and the sync that reconciles them when a connection comes back. I built the photo handling, which turned out to be the hard part because a survey can attach a dozen photos and a truck's connection is not going to upload sixty megabytes before it moves out of range again. I also built the form renderer that draws each survey type from a definition, so the office can add a form without a release. The conflict resolution screen is mine and went through three versions.

I stored records locally as the primary write and treated the server as a destination, rather than trying to write through with a fallback. My first design did the latter and it was subtly broken in exactly the case that matters — a request that leaves the phone and never gets an answer, so the record is neither confirmed nor safe to retry. Moving to local-first with idempotent upload made the failure case boring. For photos I chose to compress and upload them separately from the record, so a survey submits in seconds and its photos catch up over the next hours; the office initially objected because a record can exist without its photos, and we resolved it by showing the pending count on the record.

Crews use older Android devices that the contractor supplies and does not want to replace, so memory limits were real and were the reason photo compression happens on a background thread in batches. Sync could not depend on the app being open, because crews close it. The rollout also had a fixed pilot window with two crews, and if those two went back to paper the project was over, which concentrated attention on the parts crews touch.

The pilot crews stayed on it, which was the bar. Survey data now arrives within about two hours of the visit instead of the next morning, and transcription errors — which the office used to correct on roughly one in eight forms — are effectively gone since the data is never retyped. It has been rolled out to eleven crews. No records have been lost in about ten months, which I know because the office reconciles counts weekly and I get told when they do not match.

My senior engineer designed the sync protocol with me and made me throw away my first version, which was the right call. A backend developer built the ingestion side. The operations supervisor rode along with me for two site visits, which is where the photo behaviour and the big touch targets came from.