Field reports are written with the customer's permission. Names of individuals have been kept to roles. Numbers are theirs.
Hartley Build runs some of the largest multi-residential projects in New South Wales. When we met them, their flagship site — 240 dwellings across four blocks — was being managed on a defect register that lived in a spreadsheet, three notebooks, and the collective memory of two site supervisors. They moved the whole thing onto IssuesId in fourteen days. Here's how it went.
Day 0: the problem they actually had
The presenting problem was "we need a defects app." The real problem, which surfaced in the first hour, was that nobody could answer a simple question with confidence: how many defects are open right now, and who is sitting on them?
The spreadsheet said one thing. The supers said another. The trades said a third. Every weekly client meeting started with twenty minutes of reconciling three versions of reality before anyone could talk about the building.
That's not a tooling problem you fix with a better spreadsheet. It's a single-source-of-truth problem.
Days 1–3: the location spine
We didn't start with defects. We started with the building.
Before a single defect was captured, we built the location tree: four blocks, the levels in each, and every apartment and common area as a leaf. This is the unglamorous step everyone wants to skip, and it's the one that makes everything afterward work. Once the addressing spine existed, every defect could hang off a real place instead of a supervisor's shorthand.
- →4 blocks
- →240 dwellings
- →~60 common areas and plant rooms
- →One vocabulary everyone shared
Days 4–7: the supers, then everyone
We trained the two site supervisors first, on their own phones, on real defects. Not a demo project — their actual building. Within a day they were capturing faster than they'd written in the notebook, mostly because of two things: capture worked offline in the plant rooms, and assignment was two taps.
The tell came on day six. A super stopped sending us questions and started sending us feature opinions. That's the moment a tool crosses from "thing I'm being made to use" to "thing I have views about."
Days 8–14: trades, the client, and the first report
With the supers fluent, we brought the trades in through their own assignments and the client in through a read-only project view. By the end of the second week the spreadsheet was dead, and the weekly client meeting opened with a live number instead of an argument.
The first client meeting that started with the dashboard instead of a debate ran twenty minutes shorter. The PM said that was the moment it paid for itself.
What actually moved the needle
Looking back, the rollout didn't succeed because of any single feature. It succeeded because of an order of operations:
- 01Structure before data — the location tree first, defects second.
- 02The hardest users first — the supers, on their real building, on day one.
- 03One source of truth, immediately — kill the spreadsheet, don't run both.
Fourteen days, 240 dwellings, three notebooks retired. The defects didn't change. The arguments about them did.