Walk onto any site and you will hear both words for the same clipboard. "I'm doing the snag list." "I'm logging defects." Nobody corrects anybody, and most days it does not matter. It starts to matter the morning a contractor tells you the crack in unit 1204 was never their scope, and you go looking for the record, and the record is three photos on someone's old phone and a spreadsheet line that just says "crack, bathroom, fix."
That is the day the difference stops being pedantic.
A snag list is a moment. Defect management is the whole job.
Snagging is the walk near the end. Practical completion, a handover inspection, a client walkthrough. Someone goes room by room and writes down what is not right: scuffed architrave, a door that binds, a paint line that wanders off. You get a list, the trades come back, the items get ticked, the list closes. It is finishing work and it is bounded in time.
Defect management is the thing running underneath the whole build. Every issue, structural or services or waterproofing or a chipped benchtop, gets caught when it is found, sent to whoever owns it, worked, checked, and closed, with a record of each step. Snagging is one event inside that. Defect management is the machine the event runs on.
If snagging answers "what is left before we hand over", defect management answers "what has gone wrong on this job, who owns it, and can I prove it".
Where it actually bites
On a small job a snag list in a spreadsheet is fine. I have run jobs that way. Two trades, everyone on site, and your memory covers the gaps. The trouble is the habits that work at forty items fall apart at four hundred, and nobody notices the exact week it happened.
The first thing to go is the photos. Someone walks the site, shoots twenty of them, and reconciles them against the spreadsheet that night. Badly. That gap between what happened on site and what got written down is where your close-out time disappears, and where your evidence quietly goes missing.
Then the simple questions get slow. "What is outstanding on level three" should take ten seconds. When it takes a phone call, the register has outgrown its format.
Then the same defect gets raised twice, because two people walked the same area with two copies of the list. Now you are arguing about duplicates instead of closing anything out.
And eventually a dispute turns into archaeology. Nobody can settle "we never agreed that", so you either eat the cost or you fight about it. A proper trail ends that argument in one screen. No trail, and the loudest person in the meeting wins.
The bit people get wrong
Not everything on the walk is a defect. Some of it is a variation. Some of it is a backcharge, where Trade A does the rework but Trade B caused it and should be the one paying. And some of it is a genuine non-conformance that needs its own formal review, not a row in a snag list.
Flatten all of that into "snag, fix it" and you lose the one thing that makes each of them defensible later: who owed what, and why. We keep NCRs on a separate track for exactly this reason. It is not paperwork for its own sake. It is so the formal stuff still reads as formal months later, when a certifier or a lawyer is the one reading it.
What a growing team actually needs
Not a bigger spreadsheet. The point is to make the capture on site and the record the same thing, so there is nothing left to reconcile at 9pm.
In practice that means catching the issue where the work is: a photo, a location, and a voice note in one go, offline when the signal dies in a basement, which it will. It means a status that actually moves, open to assigned to fixed to verified to closed, where every step is role-gated and stamped against a name, so a trade cannot quietly close their own work. It means inspections that produce a signed PDF at the end instead of a punch list you retype into a report at midnight. And it means the money side, variations and backcharges, captured as structured records the accounts team can use, not rebuilt from your sent folder six months on.
Snagging does not go away. The end-of-job walk is still the end-of-job walk. But on a serious project it is the last mile of something that has been running since the first slab, not a list you start from scratch at handover.
Draw that line before your register hits four figures. Do it early and the snag list at the end is just a filtered view of a system that has already done the work. Leave it too late and, well, you already know what the spreadsheet looks like.