A field app gets used in the places where the internet is worst. A warehouse with metal racks. A site at the edge of town. A basement storeroom. If the app needs a connection to save a scan, people stop trusting it after the first lost entry and go back to paper.
So with a field app I start by deciding what happens when the signal goes. Before the first screen.
Save on the phone first, every time
Every action saves to the phone before anything else happens. A scan, a count, a photo, a note. The person sees "saved" the moment they tap, whether there is signal or not.
Sending to the server is a separate step that runs in the background. It retries on its own, and nobody has to wait for it or press anything.
This one rule decides most of the app's structure. It is much cheaper to build it in from the start than to add it after people have already lost work.
Show what has not been sent yet
People need to know where their work is. I keep it simple:
- each entry shows whether it is sent or still waiting
- one line at the top says how many are waiting
- a clear message when something was refused by the server, with the reason
That last point matters. An entry that failed quietly is worse than one that never saved, because everyone thinks it is done.
Decide who wins when two people change the same thing
Two phones can change the same record while both are offline. When they reconnect, the app has to pick. This is a business decision more than a technical one, so I ask it early:
- Counts and scans are usually added up, not overwritten. Two people scanning the same shelf should give a total, not the last number.
- Status changes often go to the latest one, but some moves cannot be undone, like closing a job. Those need a rule.
- Master data, like item names or locations, usually changes only in the back office. The phone just reads it.
Writing these rules down takes an hour with the people who do the work. Finding them out in production takes much longer.
Give every entry its own ID on the phone
If the phone waits for the server to give an entry its ID, a retry can create the same entry twice. So each entry gets its own ID when it is made on the phone. The server sees the same ID again and knows it already has it.
It is a small detail. It is also the difference between a stock count that is right and one that is off by every retry.
Keep the phone's copy small
The phone does not need the whole database. It needs what this person works on: their site, their list, this week's jobs. A smaller copy syncs faster, fits on older phones, and leaks less if a phone gets lost.
I also plan how a phone gets a fresh copy, for when a new device is handed out or something goes wrong with the old one.
Test it where it will be used
An office with good Wi-Fi tells you almost nothing about a field app. Before I call it done, I want to see it used by the real people in the real place:
Each of those finds something the office test did not.
What I need from you to start
Not a full spec. Tell me where the app will be used, what people record there, and what the back office needs to see afterwards. If you already have a system the phones should sync with, tell me what it is.
Describe it on the scope page or get in touch, and I will reply with the questions above, specific to your setup.