A field service job tracking app, and what the phone must do

The brief usually arrives as a map. A maintenance firm has eleven technicians in vans, the office spends its morning on the phone finding out where they are, and somebody has decided the answer is live tracking. Build the dots, see the vans, problem solved.

It is worth asking what the office actually does with a dot. Knowing a technician is in Nasr City does not tell you whether the job before this one was finished, whether the part was fitted, or whether the customer agreed the work was done. The office is not short of locations. It is short of two facts, and neither of them is on a map.

The two facts the office is actually chasing

Fact one: which of today's jobs will not get done, early enough to ring the customer before they ring you. Fact two: what happened at the job, in a form you can show someone three months later when they dispute the invoice.

Both are status, not position. A job tracking app that nails them is useful on day one even with no map in it at all. A map with neither of them is a toy that the office checks twice and then goes back to the phone.

This is the same mistake in a different trade, and it generalises: the visible feature is rarely the valuable one. We went through the delivery version of it in a last mile delivery tracking system, scoped around the cash, where the map is roughly a fifth of the work and the money is the hard part.

The one hard requirement: the phone has to work with no signal

Technicians work in plant rooms, basements, lift shafts and industrial units on the edge of town. Signal is not a sometimes problem there, it is the normal condition for part of every day. So every capture the app does has to complete locally and sync later, and this is the requirement that decides the architecture rather than a nice-to-have at the end of the backlog.

The web platform has a mechanism for exactly this. MDN describes the Background Synchronization API as one that "enables a web app to defer tasks so that they can be run in a service worker once the user has a stable network connection". The catch is in the same documentation: it is marked "Limited availability" and "not Baseline because it does not work in some of the most widely-used browsers", and it is available "only in secure contexts (HTTPS)".

Read that limitation carefully before you plan around the API, because the browsers it is missing on are not obscure ones. If any of your technicians are on iPhones, you cannot treat background sync as the mechanism. You can treat it as an optimisation on the devices that have it, detected at runtime, with an ordinary retry queue underneath for everyone else. Microsoft's PWA documentation shows the feature test, which is simply whether the service worker registration has a sync property.

Photos are the part that breaks the naive offline plan

The instinct is to hand everything to background sync and move on. That works for a status change, which is a few hundred bytes. It does not work for the thing field service apps capture most of: pictures.

Microsoft's guidance on background syncs in a PWA is explicit about the boundary. The Background Sync API "should be used for small amounts of data", because it "requires the service worker to be alive for the entire duration of the data transfer", and it "shouldn't be used to fetch large files, because devices can decide to terminate service workers, to preserve battery life". For large transfers the documentation points at the Background Fetch API instead, which delegates the transfer to the browser engine so neither the app nor the service worker has to stay running.

The practical consequences for a job tracking build are concrete. Compress on the device before queueing, because a modern phone camera will otherwise hand you several megabytes per photo and a technician will take six. Queue the metadata separately from the image, so the job can be marked complete the moment there is a sliver of signal even if the pictures are still waiting. And never let a failed photo upload block the status change, which is the mistake that teaches technicians the app is unreliable.

One more thing the documentation implies and buyers rarely budget for. Periodic background sync, the variant that fetches fresh data on a schedule, "only occurs when the device is on a known network" and the browser throttles how often it fires based on how much the person uses the app. It is a reasonable way to refresh a job list in the morning. It is not a guarantee, so the app still needs a visible manual refresh.

Signatures are a legal artefact, not a UI flourish

A customer signature on a glass screen is easy to build and easy to build uselessly. A scribbled path saved as an image proves almost nothing on its own, because nothing in it ties the signature to a person, a time or a version of the work.

What makes it worth capturing is the record around it: who signed, the name they typed as well as the mark they drew, the device time and the server time, the GPS fix at the moment of signing if you have one, and a snapshot of exactly what they were agreeing to. If the job sheet can be edited afterwards, store the version that was on screen, not a reference to a record that may since have changed. The question this has to survive is a dispute months later, and the only version that survives it is the immutable one.

What to build last, or not at all

Route optimisation is the usual candidate for the second phase and it is usually the wrong one. It pays only when a technician's day is genuinely a routing problem, which means many short stops with flexible order. Most maintenance work is a handful of appointments in windows the customer agreed, and there is nothing left to optimise.

Continuous location tracking deserves a harder question than it usually gets, and not only a technical one. Recording where an employee is all day is a surveillance decision with legal weight in most jurisdictions, and it changes how the team feels about a tool they have to carry. A location fix attached to each job event gives the office nearly everything it wanted from tracking, at a fraction of the cost and the friction.

If the office currently runs on a shared spreadsheet, the sequencing question is the same one we set out in internal tools for a small business, and when to stop using Excel, and the migration mechanics are in Excel to web app migration. On whether this needs to be a native app at all, the offline requirements above are the deciding factor rather than the platform, and that trade is laid out in progressive web app versus native app.

Honest limits

We have not put a price or a build duration on this, because the range is genuinely wide and driven by two things: how many trades you support and whether you need to write back into an existing accounting or stock system. A single-trade app with no integration is a different project from one that has to keep the invoice in step with a finance package.

The honest risk is adoption rather than engineering. A field app lives or dies on whether a technician with cold hands at the end of a long job will fill it in, and that is decided by how many taps the last screen takes, not by the architecture. Build the completion flow first, watch one technician use it on a real job, and fix what they skip.

And the limit worth saying out loud: this does not fix a scheduling problem. If the office is overcommitting the day, better visibility will show you the same overcommitment in higher resolution. The app will tell you the truth sooner, which is worth having, but somebody still has to act on it.