Six weeks ago someone photographed a stain on the ensuite ceiling of unit 1204 and typed a line into the register: "water mark, ensuite ceiling, check membrane." The line is still there. It is still accurate. Nothing else about that ceiling has changed.
The register is doing exactly what it was built to do, which is record that a thing exists. The part everyone assumes comes free with it, the part where the thing gets fixed and you can prove it, turns out to be a different job.
Tracking is the first thirty seconds. Management is the next eleven months.
A tracker's unit of work is the row. You add a row, you edit a row, someone ticks the row. That is a filing system, and a good filing system is genuinely useful. You can see what is open, sort by level, count by trade.
Defect management's unit of work is the transition. Who moved this from one state to the next, when, on what evidence, and were they allowed to. The row is just where the answers get parked.
There is a quick way to tell which one you are holding. Ask a question the row cannot answer. Not "is 1204 open", which any spreadsheet will tell you. Ask "who accepted 1204 as done, and what were they looking at when they accepted it."
One defect, run both ways
The ceiling stain, in a tracker.
Someone adds the row. Someone types a trade name into a column next to it. The waterproofer finds out in a phone call or a group chat, because the tracker has no way of telling him and no record that it tried. Three weeks later somebody ticks Done. The tick has no author, no timestamp you would defend, and no photo behind it. At practical completion the client asks whether the membrane was rectified or the ceiling was just repainted, and the file cannot answer.
The same defect run as work.
It gets captured where it is, against unit 1204's ensuite in the location tree, with the photo attached at the moment it was taken rather than reconciled that night. It gets a classification so it reads as a waterproofing failure and not as painting. It gets a cost category, because who pays for a membrane failure is a live question from the first day, not a discovery you make at the end.
Then it gets issued to the waterproofer, who gets a notification with a link that opens the job on his phone. He can do three things with it: say he is on it, dispute it, or mark it complete. Marking it complete is gated on a photo of the finished work. No photo, no button. It is the smallest rule in the product and it removes the single most common argument on site.
What he cannot do is close it. Trades have no defect transitions at all. He is telling you he is finished; the record still says nobody has checked. Somebody from your side goes back, looks at the rectification photo against the original, and moves it to closed. That transition carries their name.
If the contract wants more than that, sign-off is a separate step again: the nominated approver accepts the work, against a timestamp, with an optional note. "The trade says it is done" and "we accept it as done" are two different claims made by two different people, and a register that stores them in the same tick has thrown away the distinction you will want later.
The three things a tracker cannot tell you
Who closed it. A tick is anonymous by design. The moment a defect is contested, the first question is who accepted it and on what basis, and the tracker's honest answer is that it does not know.
Who pays. The contractor doing the rework and the contractor wearing the cost are often not the same party. Trade A patches it, Trade B caused it and gets backcharged. In a tracker that is a note in a comments column, which is to say it is nothing. As a structured field it flows into the report the accounts team actually works from.
What changed. Trackers overwrite. A due date moves, a description gets tidied, a status gets corrected, and the old value is gone. Eleven months later the question is not what the record says now, it is what it said in March and who changed it.
The awkward part
You do not need any of this on a small job. Two trades, everyone on site, forty items, and a shared spreadsheet is fine. I have run jobs that way and would again.
The problem is that nothing announces the crossover. There is no week where the spreadsheet stops working. What happens instead is that the questions get slower, the photos drift out of sync with the rows, and then one dispute costs you more than four years of software would have. The failure is retrospective, which is why so many teams only fix it after the expensive one.
If you want the earlier line in the sand, we wrote about where a snag list stops being enough, which is the same argument aimed at the start of the job rather than the middle.
What to ask before you trust a tool
Four questions, and they are all about after capture, because capture is the part every product demos well.
Can the person who did the work close their own record? If yes, your close-out rate is a measure of optimism.
Can you see what a field said last month, not just what it says now?
When someone marks work complete, what does the tool require of them? Anything less than evidence is a checkbox with better branding.
And can the register tell you who owes the cost, separately from who is doing the work?
A tool that answers those four is managing defects. Everything else is a very well organised list of things that are still wrong.
We set out the whole loop, capture through assignment, rectification, verification and handover, on the construction defect management software page, with the screens and an example report.