Plumbing happens in basements. HVAC happens in plant rooms and on roofs behind steel. Septic and irrigation happen where the map goes blank. If a photo app needs signal to take a photo, it is a desk app that occasionally works outdoors.
So the FieldLog crew app treats no-signal as the normal case. Every photo, note and checklist answer is written to the phone first, always. Nothing waits on the network to be saved, and nothing is lost if the app is closed, the phone dies, or the technician walks out of range mid-upload.
The queue is the product
When signal returns, the phone sends what it holds — photos first, then the report row, in an order that means the office never sees a report claiming photos that haven't arrived. If the app is killed halfway through an upload, the next launch notices the stranded item and picks it back up. If a send fails, it retries on its own clock. The technician does nothing.
That last sentence is the one we hold ourselves to. We keep trying on our own whenever you have signal. You don't have to do anything. It has to be literally true, not aspirationally true, and it has cost us real work to keep it that way.
What the app refuses to do
Never show a green tick over work that is still on the phone.
The single easiest way to lose a technician's trust is a sync indicator that lies. So the status bar says exactly one of three things: this is still on your phone, this is sending, this has reached the office. A report that hasn't left is never shown as filed. The office sees the same truth: a report is either there or it isn't, and there is no "processing" state that means "we're not sure".
Why it might not drain until Monday
Phones do not guarantee background uploads. iOS in particular may not run our code at all while the app is closed. So we design for a queue that may sit until the technician next opens the app with signal — which might be Monday morning. That's fine, and it's why the app never pretends otherwise: the evidence is safe on the phone, timestamped at capture, and it will arrive with the capture time intact, not the upload time.
What's timestamped, and by whom
The time on a photo is the phone's clock at the moment of capture, burned into the pixels. The office also records when the report actually landed, and if a phone's clock is badly off, the report says so rather than silently trusting it. Two clocks, both recorded, neither pretending to be the other.
What doesn't work offline, and why we say so
Anything that needs the server: joining a crew with a code, pulling down the day's booked visits for the first time, sending a share link to a customer. Those need signal, and the app says so at the moment you try, rather than spinning. Everything about capturing the job — the reason the app exists — does not.