Instead of one-photo-at-a-time through the OS picker, the app opens its own camera overlay, lets the crew fire off a burst, and returns every shot with a best-effort location snapshot and timestamp. If the in-page camera cannot run — an old browser, a swallowed permission prompt in the mobile app shell — it falls back to the OS camera rather than dead-ending the tap.
Also called: take site photos · progress photos · camera · photo proof · where was this taken
- 1Full-screen overlay opens the camera; up to ten shots are captured in one session
- 2Each shutter press snapshots high-accuracy geolocation with a 30 second cache
- 3Denied or unavailable location never blocks the photo — geo is best-effort
- 4Inside the mobile app shell the permission request is wrapped in a timeout, so a swallowed prompt degrades to the native camera intent
Progress photos arrive as ten separate attachments with nothing to prove where or when any of them was taken, which becomes a problem the first time a customer says the pad was poured somewhere other than the plan. The camera takes up to ten shots in a row without leaving the screen and stamps each one with coordinates and the time at the shutter. Location is best-effort — a denied permission or no signal never blocks the photo. And when the phone swallows its own permission prompt inside the app, the tap falls through to the built-in camera instead of doing nothing, which is the failure that makes a crew stop bothering.
- Photo evidence with no location or time is worth little in a dispute
- One-at-a-time photo pickers are too slow for a real progress record
- A camera that fails silently in a mobile shell kills the whole workflow
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →