The pattern is familiar in every trade. A crew fills in a sheet on site, it comes back in a van two days later, half of it is illegible, one page is missing, and somebody in the office types it all into the system while ringing the engineer to ask what happened on Tuesday.
A field service app for trades is not a mobile version of your office software. It is a different product, and the difference is that it has to work when there is no signal. That single requirement drives everything, and it forces two decisions most suppliers avoid discussing.
What offline-first actually means
The phrase is used loosely, so it is worth being precise. There are three levels and they are not the same thing.
| Level | What happens with no signal | Good enough for |
|---|---|---|
| Nothing. It needs a connection. | A spinner, then an error. The engineer writes on paper and you are back where you started, but you paid for an app. | Nobody in the field. Surprisingly common in products sold to trades. |
| Cached reading | Yesterday's job list is visible. Anything entered is lost or refused. | Someone who only needs to look things up, and even then not really. |
| Offline-first | The app works normally. Jobs, forms, photos, signatures all complete and are stored on the phone. It syncs when a connection returns, without anyone thinking about it. | Actual field work. This is the only one worth paying for. |
Ask any supplier to demonstrate the third with the phone in aeroplane mode, from opening the app to completing a job with photos. Many demonstrations quietly assume a connection and the difference does not show until week three.
Offline-first is not a feature added at the end. It changes how the whole thing is built, because the phone has to be the source of truth for a while, which is precisely why it cannot be retrofitted cheaply.
Somebody has to lose the conflict
The honest part that rarely appears in a sales conversation. If the phone holds work for hours and the office system is also live, both can change the same thing, and when the phone reconnects the two versions disagree.
There is no clever solution that avoids this. Something has to win and something has to lose, and the only question is whether you decided in advance or discovered it during a dispute about an invoice.
- The field wins for what happened on site. What was done, what was used, the photographs, the signature. The engineer was there and the office was not.
- The office wins for the commercial facts. Prices, the customer record, the schedule, whether the job was cancelled while the crew was driving.
- A human decides for the genuinely contested cases, which are rarer than people fear but must have somewhere to go rather than being silently resolved.
- Never silently discard. If a version loses, it is kept and visible. The worst outcome is an engineer's hour of work disappearing with no trace, which happens once and destroys adoption permanently.
- Timestamp on the device, not on arrival. A job completed at nine and synced at five was completed at nine, and getting this wrong makes every report wrong.
The battery problem nobody mentions
Continuous location tracking will flatten a phone before the end of a shift. This is not a bug and no amount of engineering removes it: keeping the radio awake all day costs power, and a crew whose phones die at three o'clock will stop using the app whatever it does.
- Ask why you want tracking at all. If it is for job timings, record arrival and departure rather than a continuous trail. Far cheaper in power and far less resented.
- Record on events, not constantly. Arriving, leaving, completing. Minutes of radio use per day rather than hours.
- Batch the uploads. Photographs sent one at a time as they are taken cost more power than the same photographs sent together at the next connection.
- Be straight with the crew about what is tracked, because a workforce that believes it is being watched will find ways not to be, and you will have paid for a product that produces unreliable data.
- Test on the oldest phone in the fleet, at the end of a real day, not on a new device in an office.
Where a field service app has to send its data
A field app that produces its own island of information has moved the re-typing rather than removed it. The value is in what happens after the sync.
- The job system, so a completed job is completed everywhere and the office is not chasing.
- Accounting, so what was used and what was done becomes an invoice without anyone transcribing it. This is usually where the return actually is, because it shortens the time between finishing work and asking to be paid.
- Stock, if your vans carry parts, which is where the numbers are most often wrong.
- Documents, so certificates and photographs are filed against the job rather than living in someone's camera roll.
Each of those is a connection with its own cost, and they are the part of the quote most often underestimated. Our systems do not talk to each other covers choosing which system holds the truth, which matters more here than usual because the phone is temporarily one of them. The connecting work is data pipelines.
Getting crews to actually use it
The failure that costs the most is not technical. The app works, it syncs, and six weeks later half the crews are back on paper and nobody wants to say so.
- It must be faster than paper, not merely better. An engineer at the end of a long day compares your app to a biro. Six taps to record something that took one scribble will lose, however good the reporting is at the office end.
- Design for one hand, gloves and sunlight. Big targets, high contrast, as little typing as possible. Pick from a list rather than type a description wherever it is remotely feasible.
- Photographs instead of words. A photo takes two seconds and carries more than a paragraph nobody will write. Make the camera the fastest thing in the app.
- Do not ask for anything the office does not use. Every field you collect because it might be useful is a tax on the person filling it in, and crews notice quickly which parts nobody reads.
- Involve two engineers in choosing it, including the most sceptical one. They will find the thing that makes it unusable in an afternoon, and their endorsement is worth more than any training session.
- Do not run both systems for long. A transition period where paper is still accepted becomes permanent. Pick a date, support it heavily for a fortnight, and stop taking paper.
The office frequently specifies these apps and the field uses them, which is why so many are optimised for reporting rather than for the person standing in the rain. Budget real time for that gap rather than assuming training closes it.
What it costs
| Scope | Cost | Note |
|---|---|---|
| A mobile web form, online only | $5,000 to $15,000 | Legitimate when signal is genuinely reliable. Cheap, quick, and it fails in a basement. |
| Offline-first app, jobs and forms and photos | $40,000 to $90,000 | The realistic starting point for actual field work. |
| The above, connected to job system and accounting | $70,000 to $160,000 | Where the return usually is. |
| Plus scheduling, stock and live dispatch | $150,000 and up | A different kind of project, and worth being sure before starting. |
Illustrative ranges from the kind of work we quote, not a price list. Check before commissioning anything whether a product for your trade already does this, because for common trades several do and buying beats building. Custom software vs off-the-shelf has the framework.
Not for you if
One question that settles most of the scope: what does an engineer do today when the signal drops? If the honest answer is that they carry on with paper, that is your specification, and the app has to be at least as reliable as the paper it replaces.
