A mobile app for field staff that shares one API with the company web app
How we built an offline-capable mobile app for field service staff, sharing a single API with the existing web app so jobs, photos and sign-offs stayed in one system.
The Gihonix team · · 4 min read
Key takeaways
- Working offline and syncing later suited the patchy mobile signal technicians faced.
- One shared API meant the app and the web app always showed the same job.
- Photos, notes and customer sign-off replaced paper sheets and end-of-day re-typing.
Illustrative scenario. This is based on the kind of project we deliver; client details are anonymised and no measured figures are claimed.
A building-services company in Tamil Nadu sent technicians to customer sites with paper job sheets that were re-typed into the office system at the end of each day. We built a mobile app that shows each technician's jobs, records work, photos and customer sign-off, works without a signal, and talks to the same API as the company's web application.
The challenge
Technicians left in the morning with printed jobs. On site they wrote notes, tore off a customer copy and took photos on their own phones. In the evening, or the next day, office staff typed the notes into the web application and chased missing details.
The delay caused real problems. A customer would ring to ask whether a job was done, and the office could not tell. Photos sat in personal chat apps. Parts used were remembered rather than recorded, so stock and invoices drifted.
The company already had a web application for the office, built on a Laravel backend. The question was how to give field staff a phone-based tool without building a second system that disagreed with the first.
Signal was a hard constraint. Many sites, such as basements and plant rooms, had little or none, so an app that needed constant connectivity would fail where it mattered.
What we built
Our mobile app development work produced a cross-platform app for Android and iOS, using React Native so one codebase serves both.
One API for both apps
Rather than writing a separate backend, we extended the existing web application's logic into a clean, versioned API. The office web app and the mobile app now call the same endpoints and use the same rules, so a job has one status, one history and one set of permissions.
Technician accounts use the same sign-in as staff, with short-lived tokens and a way to revoke a lost phone's access immediately.
Jobs that work offline
When the technician has a signal, the app downloads their assigned jobs, customer details and checklists. Notes, parts used, time on site and photos are saved on the phone as they are entered. When a connection returns, changes are sent to the server in the background.
We designed for conflicts: if the office edits a job while a technician is offline, the app shows both versions and applies clear rules rather than silently overwriting either one.
Photos, checklists and sign-off
Each job type has a checklist the technician completes on site. Photos attach to the job at the time they are taken, with the time recorded. The customer signs on the screen, and a summary is emailed to them automatically once the job syncs.
The office view
Because data arrives through the same API, the office sees status changes appear on the existing web screens. Dispatchers can reassign a job, and the technician's app updates when it next connects.
How we worked
We rode along with two technicians for a day each, which changed the design. Screens were simplified for use with one hand and gloves, text was enlarged, and the most common actions were moved to the first screen.
We built the API first, with automated tests covering permissions, because the two apps depend on it equally. The mobile app followed in short releases to a small group of technicians who used it on real jobs. Their feedback drove changes in each cycle: a clearer upload indicator, a safer way to discard a draft, a faster photo flow.
We paid attention to the unglamorous issues: handling interrupted uploads, large photos on slow connections, phones with little storage, and what happens when the clock on a phone is wrong. Releases were distributed through the standard app stores and a private test channel for early versions, and the official React Native documentation guided our platform choices.
What changed
Paper job sheets and evening re-typing largely stopped. The office could see job progress during the day, and customers received consistent answers when they rang.
Records became complete: parts used, photos and sign-offs were attached to each job, which made invoicing and disputes simpler to settle. Technicians spent less time on paperwork and more on the work.
Having one API also paid off in a quieter way. When the company later changed a pricing rule, it was changed once and both apps behaved correctly.
Technology
- React Native app for Android and iOS, with local storage for offline data.
- Laravel backend exposing a versioned REST API shared with the web application.
- Token-based authentication, with remote revocation for lost devices.
- Background sync with conflict handling, and image compression before upload.
- Push notifications for new or changed jobs.
Lessons
- Design for no signal. Offline-first is a requirement, not a luxury, for field work.
- Share one API. Two backends means two versions of the truth.
- Ride along first. Real conditions change the design more than any meeting.
- Test sync failures on purpose, because that is where trust is won or lost.
Planning an app for staff on the move? Talk to us about the first version.