A security patrol app is worth exactly what its checkpoint record can prove.
Every security patrol app ends up in the same argument. A client says the guard never came. The guard says they did. What settles it is not the app, it is the record the app kept: which point, which phone, what time, and whether any of it can be produced six months later. The problem has the same shape as the rest of field service apps, with one difference. Here the evidence is the product.
This page covers what a checkpoint scan proves and what it does not, whether to use NFC tags or QR codes and which one a phone app can really read, how the tour should handle a point that was missed, and what to do about the parts of a site where nothing connects.
See which tag fits your siteThe short version
A scan proves a phone was at a point, which is not the same as a patrol.
A checkpoint scan makes one small, specific claim: this phone decoded this tag at this time. That is genuinely useful, because it is checkable and hard to argue with. It is also narrow. It does not say the guard tried the fire door, looked down the service corridor, or noticed the open window on the floor above.
So the useful design question is not how to log more scans. It is what else the app asks for at the point, how it treats a point that was missed, and whether the record survives a basement with no reception and a phone that was replaced last month. A guard tour app that gets those three right is worth carrying. The rest produce tidy reports nobody trusts.
A patrol record is evidence, or it is decoration
Start from the dispute, because that is what the record is for. Most of what people call a security guard checkpoint app is one table, and a row in it earns its place only if it carries four things: which checkpoint, which user, the time the scan happened on the device, and the time the server received it. The last two are separate fields on purpose, because a device clock can be changed by the person holding the device.
Position at the moment of the scan is a cross check, not a second source of truth. A phone reporting the right tag from the far side of town is worth a question. A phone that cannot get a fix in a plant room is normal, so store a missing position as missing, never as a failure. Apps that refuse the scan until location arrives teach guards to stand outside and scan through a doorway.
Keep the patrol record separate from whatever the guard finds. A smashed light, an unlocked gate or a person on site is not a note stapled to a checkpoint. It is an event with its own life: a description, a photo, a severity and somebody who has to act on it. That belongs in a safety incident reporting app, and merging the two is how these systems become impossible to search a year later.
The two seconds at the checkpoint
Patrol checkpoint scanning is the part guards judge you on, and most of it is not about barcodes. The camera needs permission, and that prompt has to arrive with a reason the guard understands, because the person who taps no at two in the morning has just ended the patrol. The scanner hands back two things, the format it found and the data encoded in it, so checkpoint identity lives in the code you print, not in anything the phone knows.
Then design for the conditions the codes live in. They get wet, faded, sprayed and covered in stickers, so print them larger than looks necessary and laminate them. Put torch control on the scan screen, not three menus away. Give every checkpoint a short typed fallback code too, because a tag that will not read at three in the morning needs an answer other than skipping the point.
Accept too that many scans happen where nothing connects. Basements, stairwells, plant rooms, multi storey car parks and rural yards are exactly where checkpoints get placed. The scan has to be written locally and accepted on the spot, with syncing as a background concern the guard never waits for. How you queue and reconcile that on a site with no signal is its own decision, and it is worth making deliberately before the first tag goes on a wall.
The tour, the missed point and the exception
A tour is not a list of checkpoints. It is a set of points, an order or a deliberate lack of one, a window in which the tour counts, and a rule for what a missed point means. Fixed order at fixed times is the easiest thing to build and the easiest thing to predict, and a patrol pattern anybody can predict has lost most of its value. Randomising the order, or the start time inside a window, is cheap in software and expensive to game.
The missed point is where the product actually lives. Doors get locked, a floor is in use, a dog is loose, the guard gets called to the gate. If the only two states are scanned and not scanned, each of those becomes a false alarm or a small lie. Let the guard record a reason, require a note or a photo when they do, and report exceptions as their own category instead of inside a completion percentage.
Keep the tour separate from the shift as well. Whether somebody is on duty, for how long and what they are owed for it is a different record with different consequences, which is why it usually belongs in an employee time clock app rather than in patrol reporting. Tying pay to scan counts looks neat on a diagram and goes wrong the first time a tag fails.
One boundary is worth stating plainly. A patrol app that asks a guard to check in produces a log of check ins. It is not a lone worker safety system, and building one does not discharge an employer's duty to the people working alone on those sites. If a missed check in has to raise an alarm with a human being who will act on it, that arrangement exists between people, and the app is at best the thing that prompts it.
What each checkpoint method actually gives you
| Checkpoint method | Proves someone reached the point | Hard to fake from the car park | Works in the dark, in gloves | Confirmed readable in a phone build |
|---|---|---|---|---|
| Signature on a paper sheet | a signature, not a time | No | with a torch | No |
| QR code on a laminated card | Yes | No | torch on, gloves off | Yes |
| NFC tag fixed at the point | Yes | Yes | Yes | not verified |
| Contact button and a separate probe | Yes | Yes | Yes | No |
| GPS position with no tag at all | to about a street | No | Yes | Yes |
Building one around your own sites
Guard tour platforms arrive with their own tags, their own tour builder and their own client report, and for plenty of companies the first two are fine. The report is where the fit breaks. One contract wants arrival times to the minute, one wants photographs of four specific doors, one wants a signature at the gatehouse, and the platform gives you the report it has. What follows is a spreadsheet somebody rebuilds every month.
Newly is an AI app builder. You describe the app you want, including the checkpoint rules your contracts really contain, and it writes a real React Native project you own and runs it on a cloud simulator while it builds. Plans start at $25 a month and there is no free plan. Getting it onto guards' phones is the ordinary route: iOS through TestFlight using your own Apple Developer account, Android through Google Play internal testing or a standalone APK you hand out directly. It is not a guard tour platform and it does not come with tags.
Start from the report the client actually reads and work backwards to the scan. The checkpoint list is the easy half. What makes an app worth carrying round a site at four in the morning is what it does when a point is missed and somebody has to explain why.
Questions people ask about security patrol apps
It records a guard's tour of a site: which checkpoints were reached, when, by whom, and what was found along the way. The checkpoint is usually a tag or a printed code fixed at the point, and the scan is the evidence. The reason the app exists is to produce a record that holds up when a client asks whether anybody actually came.
Describe the patrols your contracts actually require
Write down the checkpoint rules, what a missed point means and what the client report has to show, then build the tour around those instead of around a tag.
Start building