The spreadsheet snagging stack, and why it breaks
Walk onto almost any construction site nearing completion and you'll find the same setup running the snagging: a shared spreadsheet, a phone full of photos, and a long email thread trying to hold it together. It works, right up until it doesn't. We have seen this on enough projects to know how it fails, and the failure is always the same shape — context leaks out of the process one small gap at a time.
The problem isn't the spreadsheet itself. A spreadsheet is a fine list. The problem is that snagging is not a list; it is a chain of evidence about a physical place, at a moment in time, agreed between specific people. Split that evidence across three tools and the links start breaking.
Here is where it actually goes wrong:
- Photos live apart from the register. The defect is row 47; the photo is somewhere in a camera roll or a WhatsApp group, named
IMG_4821.jpg. Six weeks later, nobody can reliably match them back up. - The drawing revision is lost. A snag is marked against "the north stair", but which revision of the drawing? When the layout changes, the location reference quietly becomes wrong and nobody notices until the wrong thing gets fixed.
- Who, where, and what-was-agreed go fuzzy. The register says "handle loose". It doesn't say which handle, which room, who is responsible, or what was actually agreed with the subcontractor when they walked it.
None of these are dramatic alone. Together they are why close-out drags.
The business cost of losing context
Snagging held together by spreadsheets and email doesn't fail loudly. It fails as slippage, and slippage is expensive in ways that never show up on a single line item.
Close-out delays are the obvious one. When the register can't be trusted, everyone re-inspects to be sure, and re-inspection is the most costly time on the whole programme because it happens when the client is already waiting for keys. A snag list that should close in a fortnight instead limps along for a month.
Then come the disputes. Without a clear record of who agreed what, and when, defect ownership becomes a negotiation rather than a fact. Backcharge leakage follows: work you're entitled to recover from a subcontractor quietly becomes work you eat, because you can't evidence that it was their defect, raised in time, with a photo and location attached. That's real money walking out the door — not through fraud, just missing paperwork.
The one that hurts most at handover is compliance evidence. Fire-stopping, waterproofing, structural sign-offs — the certifier wants proof each item was inspected, remedied and signed. If that proof is scattered across inboxes and phones, assembling the handover pack becomes an archaeology project instead of a button. On regulated work, missing evidence isn't just embarrassing; it can hold up occupation.
What digital defect-tracking actually changes
The shift that matters is small to describe and large in effect: capture and record become the same action. Instead of noticing a defect, photographing it, then later transcribing it into a register, you raise the defect where you're standing, and the photo, location and details are attached in the same motion. Nothing has to be reconnected later because it was never separated.
Good defect-tracking software builds on that single change:
- Photos and annotated drawings travel with the issue. You mark up the exact spot on the current drawing, and that annotation is the defect. The revision is baked in, so the location can't drift.
- Every issue is anchored to a location. Building, level, room, or a specific asset — not a free-text guess. Filter the register to "Level 3, wet areas" and it is genuinely those items and nothing else.
- Assignment and audit log are automatic. The issue goes to a named responsible party, and every status change, comment and re-inspection is timestamped. "Who agreed what, when" stops being a memory test.
- Handover packs are generated, not assembled. Because the evidence was captured in structured form throughout, the signed PDF pack at the end is a report, not a fortnight of collation.
IssuesID — the construction quality platform we built at CodeDrips — is the concrete example we reach for, because it was designed around exactly this problem. Defects carry their photos, annotated drawings, correspondence and full audit log; inspections run off reusable QA checklists with digital sign-off; and everything anchors to a locations tree so nothing floats. The audit trail is tamper-proof by design — drawing revisions are immutable, items are withdrawn rather than deleted, every change is logged — which is precisely what makes handover evidence complete rather than hopeful. We wrote more about the thinking behind it in the IssuesID announcement post.
Why offline capture is non-negotiable
Here is the detail that quietly sinks a lot of otherwise-good software: sites have no signal. Basements, lift shafts, plant rooms, steel-framed floors, the far end of a partly-clad building — these are exactly where the tricky defects hide, and where your phone shows no bars.
If the tool needs connectivity to capture, people stop using it on the walk and revert to the camera roll "just for now". That's how you end up back at the spreadsheet stack, having paid for software you route around.
Offline-first capture removes that failure mode. IssuesID is a progressive web app that installs to the home screen and captures defects, photos and annotations with no connection at all, then syncs automatically when signal returns — no app store, no waiting on IT. The person on the walk never has to think about it, which is the whole point. Software only helps if it survives contact with the site.
Moving off spreadsheets without the pain
The fear that keeps teams on spreadsheets is migration — the belief that switching means a big-bang data project nobody has time for. It doesn't have to.
The trick is to move at a natural boundary rather than mid-flight. You don't need to import three years of closed history; that history is done. Start the next project, or the next distinct area of a live project, in the new system and leave the old register where it is as a read-only archive. Trying to backfill everything is what makes migrations painful, and it buys you almost nothing.
A sensible sequence looks like this:
- Model the locations first. Get your buildings, levels and rooms in before anyone raises a defect. On IssuesID you can print QR codes per location and stick them up on site, so a scan jumps straight to the right list — this is what makes field adoption stick.
- Run one team, one area, as a pilot. Prove the loop end to end — capture, assign, remedy, sign off, generate the pack — on a slice small enough to fix quickly if something's awkward.
- Standardise your inspection checklists once, then reuse them. Reusable QA templates are where the time savings compound across every subsequent project.
- Keep the old spreadsheet available, not active. No one has to trust the new system on faith while the archive is a click away.
Done this way, the switch is additive rather than disruptive. The team learns the tool on real work at low stakes, and the value shows up on the first handover pack that assembles itself.
Spreadsheets got snagging this far because they're flexible and everyone has one. But flexibility is the wrong virtue when what you need is an unbroken chain of evidence about a physical place. If your close-outs are dragging, your backcharges are leaking, or your handover packs are a scramble, the fix isn't a better spreadsheet — it's making capture and record the same act. If you'd like to see what that looks like on your own project, request a demo and we'll walk it through with you.
