You are in a slab basement with zero bars. You record a thirty-second note about a moisture reading and a stain pattern. The honest question every inspector should ask before trusting a tool with that note is simple: where did it just go, and is it still there when you climb back out? The answer depends entirely on whether the app was built to work offline or just looks like it does — and it is the flip side of why your phone's voice-to-text dies in a basement in the first place.
Where does a voice memo go when you have no signal?
If the app is built right, it goes into local storage on your own device, not the internet. A browser app can record audio locally with MediaRecorder (MDN, MediaRecorder API) and then save that audio blob into IndexedDB, a database that lives in the browser on the device itself and persists across page reloads and app restarts (MDN, IndexedDB API). No network is involved in either step. The memo is sitting in a real database on your phone, the same as a photo saved to your camera roll, waiting.
If the app was not built that way, the memo may exist only in volatile memory and can vanish on a reload or a tab close. That is the difference between an app that handles your field reality and one that merely runs in a browser.
How does it get to the server later, without you babysitting it?
Through a sync step that fires when connectivity returns. A progressive web app uses a service worker, a script the browser keeps running in the background, to manage caching and to coordinate work that should happen when the network is available (MDN, Service Worker API; MDN, Progressive web apps & service workers). The pattern is: queue the memo locally while offline, and when the device is back online, push the queued items up. You do not stand in the driveway tapping retry. The queue drains itself once there are bars.
So the full path is local capture, local persistence, automatic sync. Each stage is designed to survive a dead signal, because the whole point is that the field has dead signals.
Why this is the difference between trusting a tool and not
Inspectors have lost notes to apps that assumed connectivity. One reload in a parking garage, one "your session expired," and the finding you dictated under a house is gone, and you cannot re-create the moment. A tool that persists captures to on-device storage first removes that failure mode. The memo is durable the instant you stop recording, before any server ever hears about it. That durability, not a fancy interface, is what lets you actually rely on it in a crawlspace.
The test for any field capture tool is brutal and simple: turn airplane mode on, record something, force-close the app, reopen it. If your note is still there, the tool respects how you work. If it is gone, it does not.
Capture to the device first, sync later
Capture to the device first, persist immediately, sync automatically. Record the memo with MediaRecorder, store the blob in IndexedDB the moment recording stops, and let a service worker push the queue when the connection comes back. Same approach for photos and form data. The field is treated as offline by default, and online is the happy accident that lets the queue flush.
That is the architecture MoldMind uses for field capture. Voice memos, photos, and form entries are saved to on-device storage as you work and sync when you reconnect, then your audio is transcribed and reformatted into report findings you review and approve. It is built around the basement, not the office. The sample report shows where those synced field notes end up.
Sources
- MDN, MediaRecorder API: records audio locally on the device.
- MDN, IndexedDB API: an on-device browser database that persists across reloads and restarts.
- MDN, Service Worker API: a background script that coordinates caching and work to run when the network is available.
- MDN, Progressive web apps & service workers: the PWA pattern for offline-first capture and later sync.