Hand over a 400-unit project and the defects arrive in the thousands within the first weeks of the liability period. Every unit files its own list, and the pile in front of the defect team looks like three thousand separate jobs to work through. The instinct — the one that quietly defeats defect management for large developments — is to start at the top and grind down: assign a contractor, book a repair, close the ticket, move to the next. Three thousand times.
That instinct treats volume as an endurance problem. It isn’t. It is a blindness problem.
Defect Management for Large Developments Isn’t a Tracking Problem
The thousands of defects on a large project are not three thousand unrelated faults. A large share of them are the same fault repeating. The same door misaligned across an entire block. The same hairline crack on one floor’s plasterwork. The same tap fitting failing, unit after unit after unit. Those clusters do not come from two hundred bad units. They come from one subcontractor, one material batch, or one stage of construction that went wrong once and got repeated everywhere it was applied.
Work the pile one ticket at a time and you will never see this. You fix two hundred symptoms, dispatch two hundred separate repair visits, and the root cause is never named. Worse, you learn nothing — the same fault walks straight into your next project because nothing in the process ever told you it was a pattern rather than bad luck.
So the real question on a large development is not how do we get through three thousand tickets. It is how many distinct problems are actually in this pile — and who caused each one.
The Taxonomy Is Not for Tidiness
This is why the way a defect is recorded matters more at volume than anywhere else. When iNeighbour files every defect against a fixed Category → Type → Item taxonomy — fourteen built-in categories spanning electrical, plumbing, structural, doors, windows and more — it is not doing housekeeping. It is making the pattern visible.
The moment every “door — hinge — misaligned” is classified the same way instead of described in three hundred different phrasings, the cluster surfaces on its own. Two hundred scattered complaints become one recognisable fault appearing across a specific block. That is the difference between a pile you dig through and a map you can read. Free-text reports on a spreadsheet cannot do this, because the same fault is written a different way every time and never adds up to anything.
Tie Every Defect to Who Owns It
Seeing the cluster is only half the value. The other half is knowing who is answerable for it. Because contractors are registered in the system and each defect is assigned to the responsible team, the pattern is not just visible — it is attributable. When the same fault appears across forty units, you are not looking at forty problems to chase; you are looking at one conversation to have with one contractor, backed by forty documented, pinpointed, photographed tickets.
That changes the developer’s leverage entirely. Instead of quietly absorbing repeat repairs unit by unit, you go back to the source with evidence, negotiate rectification across every affected unit at once, and hold the party who caused it accountable for fixing it properly — not just patching the units that complained loudest.
Fix the Cause, Not the Symptom
Run this way, volume stops being a burden to survive and becomes something useful. The at-a-glance ticket status shows which blocks and categories are concentrated, so the team works from where the problems actually cluster rather than reacting to the order complaints happen to arrive. Aging counters and due dates keep individual repairs moving. But the strategic gain sits above the individual ticket: you rectify at the root, you resolve whole clusters in one coordinated push, and you carry the lesson into how you brief and inspect on the next project.
And when the development is handed to the incoming JMB, they inherit more than a closed defect list. They inherit a documented record of what failed, where, and who fixed it — a genuine quality history of the building rather than a spreadsheet no one can vouch for.
Three thousand tickets tell you how much work you have. Two hundred faults tell you what actually went wrong — and only one of those numbers helps you build better next time.