The worst place to require a perfect connection is the place the work happens: a basement mechanical room, a steel building, a rural driveway. If capture only works on office Wi-Fi, you did not build a field product.
ServiceBrief AI is a web app with PWA support, not a pair of native stores. This post is that choice and what offline is for.
Native was out of scope on purpose
Native apps are a real product line: review cycles, two codebases, push-notification politics. The brief was a working operations product in the browser, installable on a phone home screen, with an offline path for the moment of capture. That is a trade. It is an honest one. We did not advertise an App Store listing we did not have.
Offline is for capture, not for pretending the whole back office is local
The useful offline moment is: record or type the note now, sync when the radio comes back. The useful online product is still review, knowledge, quotes, and billing. If you try to replica the entire multi-tenant API into IndexedDB on day one, you will ship a sync bug instead of a report.
A dedicated offline fallback route exists so a technician does not stare at a blank generic browser error. Marketing can talk about offline jobs because the product actually has that section — not because “PWA” was a buzzword in a deck.
Design for thumbs, but do not hide the job
Job detail on a phone shows the slices a tech needs (overview, follow-ups, quotes) without pretending a six-tab desktop layout fits a 390-pixel width. Voice capture has to be obvious. Managers still get the wide report on a laptop. Same system, different density.
What we tell buyers
Install the app on the phone. Capture on site. The office reviews when they are at a desk. If a customer later needs a fully native dispatcher with turn-by-turn and background GPS, that is a different product (and ServiceBrief does not claim it). Be explicit and you will not spend the implementation budget on a store listing that was never the wedge.