Journal/Field notes

Real-time defect tracking, three floors underground

Three items found at 10:40 in a basement with no signal. Real-time is the wrong thing to ask for. What matters is that the defect exists the moment it is found, with the right time and place on it.

A two-colour risograph poster of a phone under a sprinkler main with one orange location pin on its screen
WP
Will PrinmanCo-founder
28 September 2026·5 min read

Basement 3, a car park slab with a sprinkler main being tested overhead. The hydraulic consultant is walking it with your site engineer and finds a hanger that was never torqued, a weeping joint at a tee, and a pipe clashing with a cable tray that went in last week. Three items, found at 10:40, in a place with no bars of signal and never will have.

Every piece of software that sells itself as "real-time defect tracking" has to answer one question here. What happens to those three items between 10:40 and whenever the engineer walks up the ramp?

Real-time is the wrong thing to ask for

Here is the opinion. "Real-time" is a sales word, and on a construction site it asks for the wrong property. Nobody needs a defect to appear on a dashboard in the office within two seconds. What they need is for the defect to exist the moment it is found, with the right time and place on it, and to reach everyone who needs it before anyone acts on the old picture.

Those are different requirements. A cloud app that is genuinely real-time when it has a signal does worse underground than a slower one that saves locally, because the real-time one turns into a camera roll. The engineer takes three photos, means to log them later, and logs them at four in the afternoon from the site shed, from memory. The hanger was on grid C4 or C5. The time on the record is 16:02.

That record is now wrong in two ways, and it is wrong in exactly the way that matters in a dispute.

What has to happen at 10:40

The defect has to be written down at 10:40, on the phone, in the basement. Photo, location, trade, priority, and a description short enough to type with cold hands. That means the app has to work with no connection at all, not "degrade gracefully", and it has to work because the screens are already on the phone rather than fetched each time.

That is how IssuesId is built. It is a web app you install to the home screen, the whole app is stored on the phone the first time you open it, and capturing a defect offline is the normal path, not an emergency mode. The three items go into a queue on the phone. A counter in the top bar says three are waiting.

When the engineer reaches the ramp and the dot goes green, the queue sends in the order things were captured. The weeping joint does not arrive before the hanger because its photo was smaller.

The rough edge, stated plainly

The defect record's own created time is when it reached the server, not when it was typed. If the engineer stays underground until lunch, the three items show as raised at 12:15.

What carries the 10:40 is the photo. The photo keeps the time the camera saved into the file, and on the phones we see that is the moment the shutter went, so the evidence says 10:40 even if the record says 12:15. We would rather tell you that than let you find it in a claim. If the exact capture time of the record itself matters on your job, the photo is where it lives, and the photo metadata keeps it.

Location is the other half

The other thing a camera roll loses is where. "Basement 3 near the pump room" is a description, not a location, and six weeks later nobody can find the hanger.

Log it against the location tree, Basement 3, Grid C, Sprinkler main, or drop a pin on the drawing. If there is a QR label on the column, scan it, and the location fills itself in. The QR pages work offline too, which matters, because the only places worth putting a QR label are the places where nobody can remember where they are.

The phone also asks for its position when you raise a defect. Underground that is usually useless, and that is fine. The location of record is the tree, not the GPS.

Before anyone acts on the old picture

This is the half of "real-time" worth keeping. The sprinkler contractor is going to lag the main on Thursday. If the weeping joint is not in front of them by Wednesday, it gets lagged over.

So the part that has to be quick is not the dashboard, it is the assignment. When the queue drains, the item is issued to the fire services contractor with a due date, and the email with the link goes out then. They open it on their phone, no account, see the photo, fix it, and send back a photo of the fix. They cannot close it themselves. Someone on your side does that after looking at the photo.

Put an overdue rule on it and nobody has to remember that Thursday matters.

What to ask a vendor

If you are comparing tools, skip the real-time question. Ask these instead, on site, with the phone in flight mode:

Can I raise a defect with a photo and a location right now? Where does it go? When I turn flight mode off, what time does the record say? Does the photo keep its own time?

Most demos happen in an office with good wifi. Do yours in the basement. The mobile defect tracking app page shows what that looks like in IssuesId, and the construction defect management page shows where those three items go after the ramp.

IssuesId