A sales rep walks into a shop on the edge of town, opens the company app to record an order, and the screen spins. The signal bar shows one line. The order goes onto a scrap of paper, gets typed in later, and sometimes never does. Multiply that by a hundred reps and a month, and the company is making decisions on data it does not have.
Software for people who work in the field has to be designed for that moment. This article explains why, with the numbers, and sets out the design rules we follow.
Coverage is not connection
The GSMA's State of Mobile Internet Connectivity research makes an important distinction. The coverage gap is people who live where there is no mobile broadband. The usage gap is people who live within coverage but do not use mobile internet, because of cost, devices, skills or reliability.
Globally, the coverage gap has fallen to a few per cent of the population. GSMA reported that of the 40 million people who gained coverage in 2024, three-quarters were in Sub-Saharan Africa. But the usage gap is enormous: about 3.1 billion people, roughly 38% of the world, live within mobile broadband coverage and still do not use it.
For field software, the lesson is that "there is 4G here" does not mean "my users will be online". Data costs money, phones run out of storage and battery, and signal inside a warehouse or a rural clinic is not the same as signal on the map. Even where people are connected, the connection comes and goes.
Design for the phones people actually carry
According to StatCounter, Android ran on about 83% of mobile and tablet devices in Africa in September 2026, with iOS on about 17%. GSMA projected smartphone adoption in Sub-Saharan Africa rising from about half of connections in 2022 towards nearly nine in ten by 2030.
That growth is mostly in affordable Android phones with limited storage and memory. An app that needs a 200 MB download and a recent flagship to run smoothly is designed for a different market. For field teams, the target device is a modest Android phone that is also somebody's personal phone, with WhatsApp, photos and a dozen other apps competing for space.
What the web can do now
Progressive web apps, websites that can be installed to the home screen and behave like apps, have become a practical choice for field software:
- Installation is light. There is no app-store download, and updates arrive automatically.
- Service workers let the app load its screens from the phone itself when there is no network.
- Local storage in the browser lets the app keep records on the device until they can be sent.
- One codebase serves Android, iPhone and desktop managers alike.
There are limits. The Background Synchronization API, which lets a web app send queued data after the user has closed it, is marked by MDN as having limited availability. It works in Chrome and Edge, which covers most Android users, but not in Firefox or Safari. So an offline-first web app should also try to send data whenever it is opened, rather than relying on background sync alone.
Our design rules for field software
1. Every action works offline first
Recording a visit, an order or a note should save to the phone immediately and show as done. Sending it to the server is a separate step that happens when it can. The user should never have to wait for the network to finish their work.
2. Show sync status honestly
A small, clear indicator should tell the user what has been sent and what is still waiting. Hidden sync creates distrust, and reps go back to paper.
3. Make conflicts rare and resolvable
If two people edit the same record while offline, the app must decide what happens. Designing records so that most actions add new entries, rather than overwrite old ones, avoids most conflicts entirely.
4. Keep the download small
Every megabyte costs the user money. Compress images before upload, load only the data a rep needs for today, and avoid heavy libraries.
5. Respect the battery
Location tracking is valuable for managers and expensive for phones. Record location at meaningful moments, such as clocking in or checking in at a visit, rather than constantly.
6. Make the rules of the working day clear
Simple rules prevent messy data. In Wayfen, for example, field reps clock in before they start work and cannot sign out while still clocked in, so the day's record is always complete.
7. Speak the user's language
Field teams are rarely all fluent in one language. Every screen should be translatable, and simple words beat technical ones.
8. Test in the real world
Test on a low-cost phone, on a slow network, in airplane mode and with the battery saver on. If it works there, it will work anywhere.
The payoff
Offline-first design is more work at the start. It pays off in the only metric that matters for field software: whether people actually use it. When the app works in the shop on the edge of town, the data arrives, the manager can act on it, and the monthly report writes itself.
Sources
- GSMA, More than 3 billion people remain offline despite available mobile internet, September 2025.
- GSMA, State of Mobile Internet Connectivity, 2026.
- Ecofin Agency, GSMA expects SSA smartphone adoption to grow to 87% by 2030, March 2023.
- StatCounter, Mobile and tablet operating system market share, Africa, September 2026.
- MDN Web Docs, Background Synchronization API.
- Can I Use, Background Sync API browser support.