A field app that needs signal is a field app that fails

A field app gets its real review beside a gate, not in a boardroom. The demo runs on office wifi with a full battery and someone’s full attention. The job runs in the ute, on a hot site, at the back of a property with one bar, in the ten minutes between calls, one-handed. Those are different worlds, and an app built for the first one dies the moment it meets the second.

That’s the whole game with field software, and it’s where most of it goes wrong. The build that impressed everyone in the meeting is the same build the crew quietly abandons in week two, because it asked them to stand still and wait for a spinner while a job was going on around them. Design for the demo and you’ve built a thing that works everywhere except where the work happens.

Here’s the pattern before the app exists. An ag services crew runs spraying and fencing jobs west of Toowoomba, on properties where coverage drops out ten minutes past the highway. Jobs go out on paper because paper never buffers. Photos end up on three different phones. The paperwork comes back on Friday, most of it, and the office spends Monday deciphering handwriting and chasing the sheet that stayed on the dash. The invoice for Tuesday’s job goes out ten days after the work, and the customer has already rung once to ask what it covers. Nobody in that story is lazy. The tools just don’t survive the conditions, and a field app that also doesn’t survive them fixes nothing.

Offline is the foundation, not a feature

Half of Queensland field work happens in patchy coverage, so this is the decision everything else hangs off. If the app needs a live connection to save a note, a photo, a signature or a status change, staff will try it twice, get burned by lost work, and go back to paper. Now you’ve got worse records than before and a monthly licence bill on top. That’s the failure mode, and it’s common, and it’s entirely avoidable.

Offline-first means the app works fully with no signal and syncs when it can, and that’s not something you sprinkle on at the end. It forces real decisions up front: what lives on the device, what happens when two people edit the same job and both come back into range, when sync runs, and what a worker sees when it fails. Those calls belong in the architecture from day one. Try to retrofit them in the last week of the build and you’ll either blow the timeline or ship something that loses data, and losing a plumber’s job notes once is how you lose the plumber.

Every tap is a tax when you’re standing at a gate

Nobody wants to thumb through a twelve-field form on a phone with one hand while a truck idles. The job is to shrink the distance between doing the work and recording it, and that’s a design discipline, not a nice-to-have.

Default everything you can. Reuse the job details the app already knows instead of asking again. Scan a barcode or a rego instead of typing it. Let someone snap a photo where a paragraph would do. Offer short tap-lists over free text. Keep the keyboard shut as much as possible, because the keyboard is where field data entry goes to die. Every field you can remove is a field that gets filled in correctly instead of skipped, and skipped fields are how a records system quietly becomes fiction.

The evidence is worth more than the record

A photo, a GPS point, a timestamp, a signature, a ticked checklist, a quick note, all pinned to the right job. That string of small things is evidence, and evidence is what you reach for when a customer disputes the invoice, an auditor wants the maintenance history, or someone claims the work never happened. That’s often the strongest reason to build the app at all.

But it’s only evidence if it’s attached to the right job, asset, customer or site automatically, at the moment of capture. A folder of loose photos with no context is barely better than the camera roll, and asking a tired worker to manually tag each one is asking for it not to happen. The app does the filing, or the filing doesn’t get done. Get this right and the payoff is boring and constant: the invoice dispute that used to be a week of he-said-she-said closes in one email with three timestamped photos attached, and the compliance audit that used to mean a fortnight of folder-diving becomes an export.

The app is only half the job. The other half is the office.

A field app that’s a data island is a disappointment waiting to happen. The value shows up when finishing a job on the phone actually moves the business: the schedule updates, invoicing kicks off, the customer gets a message, a follow-up task appears, the dashboard refreshes. That’s the difference between a digital worksheet and a system.

Which means the app is usually the small, visible tip of a build that’s mostly integration underneath, wiring the field into the systems the office already runs on. If a vendor quotes you a field app and never mentions how it talks to your existing systems, they’ve quoted you half a product and you’ll feel the other half as manual re-entry.

Cheap Androids, shared logins and a battery on 40 per cent

Design for the devices people actually carry, not the flagship in the mockups. Field crews run mid-range Androids a couple of years old, with cracked screens, low storage and batteries that have been through two summers, and the phones are often shared between whoever’s rostered on. An app that assumes a current iPhone and a personal login will misbehave in ways the office never sees.

Shared devices break the tidy one-user-one-login model, so switching workers has to be a two-tap job, or every record gets logged against whoever signed in first and there goes the evidence trail. Battery matters more than anyone admits at scoping: a worker who learns the app flattens their phone by smoko deletes it in week one. Photos and sync are the hungry parts, so compress on the device and let the heavy sync wait for wifi or the depot. And test in the sun, on the actual dash mount, with gloves on if that’s how the crew works, because a screen that passes in the office can be unreadable at midday in January. None of this is glamorous engineering. All of it decides whether the app is still on the phone in month three.

Give it to your most sceptical crew first

Rollout decides as much as the build does. Don’t launch to the whole company. Pick one crew for a two-week pilot and make sure it includes the sceptic, the one who reckons the clipboard is fine and has twenty years of evidence for it. If the app survives that person, it’ll survive the company. If it doesn’t, better to hear it from five users than from forty, after the quiet fallback to paper is entrenched and the licence money is spent. Run the pilot in a busy stretch, too, because a trial in the quiet weeks proves nothing.

Run paper in parallel during the pilot, then retire it deliberately, on a date, with the crew told why. Keep both forever and the app is optional, and optional field software always loses to habit. Be straight about cost too: a proper offline-first field app wired into the office systems is a five-figure build, more when the sync logic or hardware gets complicated. Put that against what the re-keying, the lost job sheets, the disputes you can’t evidence and the ten-day invoice lag already cost every month, and the maths is usually less scary than the quote.

Design for interruption, because the work is nothing but interruptions

Field work gets interrupted constantly, so the app has to assume it. Save progress as it goes. Cope gracefully with a half-finished record. Make required fields obvious so nobody’s hunting for why they can’t submit. Never punish someone for getting pulled onto something else mid-form and coming back an hour later.

The small stuff carries all of this: tap targets big enough for real thumbs, contrast you can actually read in direct sun, a status that’s clear at a glance, error messages in plain words, and no clever gesture standing between a worker and finishing a task. You know a field app has worked when it disappears into the day and staff use it because it beats the old workaround, not because they were told to. So test it where the work is. If it survives a wet morning, a flat battery and no bars at the back of a property, the office was never going to trouble it. If you’re weighing up a field app, tell us where your crews actually work and we’ll build for that, not for the demo.