Scheduling, patrols and attendance for staff who are never at a desk

Workforce management for organisations running security staff and lone workers — scheduling and rostering, time and attendance, guard patrols verified by GPS and QR checkpoints, automated check-calls for people working alone, incident reporting, leave, and staff vetting.
Two very different users share it. In the control room, someone needs the whole picture: who is on, who is late, who has missed a check-call. In the field, someone needs to do one thing quickly, in the dark, with one hand, on a bad connection.
I worked across the web platform and the React Native app.
Almost every difficult decision here comes from the field user.
They are outdoors, often at night, frequently alone, on a phone with an unreliable signal, and they are not enthusiastic about your software. A clock-in that takes three taps and a good connection is a clock-in that quietly does not happen — and that failure does not stay small. The roster is wrong, so the control room is looking at a site it believes is covered, and payroll is wrong at the end of the month.
The check-call feature makes the stakes plainer than most software ever gets. It exists so that if a lone worker stops responding, somebody notices. A missed notification there is not a bug report.
Full-stack across the web platform and the React Native app for iOS and Android.
Verification is the whole product. Anyone can build an app with a clock-in button; the value is in being able to show that a person was actually at a checkpoint at a particular time. That is why patrols are tied to physical QR codes and GPS rather than to a tap — it turns a claim into evidence, which is what the customer is really buying.
And the design follows the user's conditions, not the demo's. Every field interaction is built to be finished in seconds, one-handed, with the phone barely connected.
A React web platform for the control room and a React Native app for the field, over a PHP backend. The scheduling and verification rules live on the server so that the control room's view and the field's actions cannot disagree about the same shift.
The mobile app is built for one-handed use in poor light with a poor signal: few taps, large targets, and clear confirmation that something registered — because a user who is unsure whether their clock-in worked will do it again, and a duplicate is its own problem.
Workforce software shaped by the conditions its field users are actually in — where verification is the product, and where the difference between a two-tap action and a four-tap one shows up in the roster and the payroll.
If this sounds familiar
Building something similar?
Most of these problems show up again in different clothes. Describe yours and I will tell you what I would look at first.