Why site inspection apps fail where the work is: dead zones, camera rolls and the defect record
Browser-based inspection tools stop working in the parts of a new-build site where defects are found. What happens to the record when the signal drops, why it matters in a DLP dispute or an NHQB complaint, and what offline-first capture requires.
Most site inspection tools are built on the assumption that the inspector has a connection. On a finished development that assumption usually holds. On a live new-build site it often does not. Basements, plant rooms, steel-framed cores and rural plots before the mast is live are the places where defects are found, and they are also the places where a browser-based tool stops responding.
What happens next is predictable. The work does not stop, so the evidence goes somewhere else: the phone camera roll and a WhatsApp thread, with the defects retyped later at the desk. The defect usually gets fixed. The record of it is weaker than it should be, and the weakness only shows when the record is tested.
What happens when the signal drops
A browser-based inspection tool is a web page. Every action it takes, whether opening a plot or uploading a photo, is a request to a server. When there is no signal, the request fails. Some tools cache a little. Most spin, time out and lose whatever was half-entered.
The inspector adapts. Photos go to the native camera because the native camera always works. Notes go to WhatsApp because the message will send when the phone finds a bar of signal on the way back to the cabin. The checklist is completed from memory that evening. Each of these is a rational response to a tool that has stopped working, and each one strips the capture of the structure that made it useful.
The camera roll photo has a timestamp and, if location services are on, a coordinate. It does not know which plot it belongs to or which checkpoint it was meant to evidence. A WhatsApp message has a sender and a time. It cannot be searched by plot or assigned to a contractor. A checklist retyped hours after the walk records what the inspector remembers, with the context gone.
None of this is the inspector's fault. It is a design decision in the tool: the server is treated as the record and the device as a thin window onto it. On a site with no signal the window is blank.
Why it matters for developers
The defect record is what a developer relies on when a homeowner disputes a defect during the defects liability period, which typically runs for 12 or 24 months from completion. The question in a dispute is rarely whether the defect exists. It is what was found at pre-completion inspection, when, by whom, and what was done about it. A GPS-tagged photo annotated on the spot and pinned to a floorplan answers that question. A camera roll image sorted from memory a week later does not.
The same record is what the New Homes Quality Code asks for. The Code, administered by the New Homes Quality Board, requires registered developers to have a pre-completion inspection process and to keep records of complaints and defects. Where a complaint escalates, the New Homes Ombudsman Service will ask to see those records. A process that exists on paper but produces evidence assembled after the fact is a weaker position than one where the capture is timestamped at source.
Part L adds a further evidence requirement. Under the 2021 uplift to Approved Document L in England, in force from 15 June 2022, the BREL report must be supported by photographic evidence. Those photographs are taken during construction, often in exactly the locations where signal is worst. If the Part L inspection is run from a browser tool that cannot load, the photographs end up in the camera roll with the same problem as every other defect image: no link to the plot or the checkpoint they are meant to evidence.
What offline-first actually means
"Works offline" covers a wide range of behaviour, from a tool that holds one form in memory until the page is refreshed to one that treats the device as the primary record. The difference matters on site, and it comes down to four properties.
- The on-device store is the source of truth. Every capture is written to the device first and is considered saved at that moment. The server is a destination for sync, and the app does not wait for it.
- Background sync is conflict-safe and idempotent. When the device finds a connection, it reconciles what was captured with what is already on the record. Idempotent means the same capture uploaded twice, after a connection dropped mid-sync, produces one defect. Conflict-safe means two changes to the same record made while apart are reconciled rather than one silently overwriting the other.
- Floorplans are cached before the walk. Pinning a defect to a plan gives it a location a contractor can find without a phone call. That only works offline if the plan is already on the device.
- Photos are GPS-tagged and saved to the device instantly. The coordinate and the timestamp are attached at capture, alongside the plot and room the inspector had open, so the image carries its context rather than acquiring it later from memory.
The practical test is straightforward. Put the phone in aeroplane mode, walk a plot, raise a defect with a photo and a floorplan pin, complete a checklist, then turn the connection back on. If everything appears on the plot record once, with its location and timestamp intact, the tool is offline-first. If anything is missing or duplicated, it is a browser tool with a cache.
What to watch
- Where inspections are actually run. Ask site managers which parts of the current developments have no usable signal and what they do there today. The answer is usually the camera roll.
- Part L photographic evidence. Check whether the photographs supporting the BREL report are linked to the plot and checkpoint they evidence, or sit in a folder named after the site.
- Record integrity through the DLP. For any plot with a live dispute, test whether the pre-completion inspection record can be produced from a single source, with timestamps and photographs intact.
- Sync behaviour. For any tool described as working offline, ask what happens when a connection drops halfway through an upload, and whether the result is one record or two.
How Guided Home helps
When the evidence that will be tested in a DLP dispute or an Ombudsman complaint is captured in the places on site with the worst signal, the capture tool has to work there first and sync second. Guided Site, the iOS app for site teams, is built in that order. Defects, photos, video, annotations, floorplan pins and checklists are written to the device the moment they are captured. Photos are GPS-tagged and saved instantly. Plans are cached, so a defect can be pinned with a single tap and no connection. Custom forms and Part L inspections run on the same walk, offline. When the device is back online, background sync reconciles everything automatically, conflict-safe and idempotent, so nothing is duplicated or lost.
What Guided Site captures lands on the same plot record as the Inspections and Defects module. The priority and owner visibility set on site carry through. In the office the defect is assigned to a contractor with an SLA, and the checklist it came from, with its pass/fail/N/A checkpoints, is saved as a signed PDF to the plot document vault. Through the Defect Connectivity Hub the same defect syncs two-way with Procore, Trimble Fieldview, Access Coins, Salesforce or Dynamics 365, so the contractor sees it in the system they already use and its status flows back to the record.
The completion documentation for the plot sits alongside the defect history in Document Assurance, so the Part L photographs and the pre-completion inspection record are read together rather than reassembled from separate folders when a complaint arrives. The Executive Dashboard gives leadership the portfolio view of open defects and DLP exposure across every site, without waiting for each site manager to compile a report. Where a defect is marked visible to owner, it surfaces in the Homeowner Portal, so the resident sees the same item and the same status as the developer.
Sources