Every system that touches the gate eventually runs through the security guard. They are the first interaction a visitor has with the society and the last line of accountability when something goes wrong. Yet the tools they work with are the most neglected part of the building's operation.
The paper register is still there in most societies. The intercom dials a flat that may or may not pick up. The guard's personal phone fills the gap, with a contact list of resident numbers in a notebook taped to the wall. Three different systems, none of which talk to each other, all of which depend on the guard's memory and goodwill to keep working.
If you want to fix community management at a society, you start with the gate. And if you want to fix the gate, you start with what the guard is holding.
What the guard's day actually looks like
A visitor arrives. The guard asks who they are visiting. They look up the flat number — sometimes from memory, sometimes from a list. They write the visitor's name and the time in the register. They pick up the intercom and dial the flat. The intercom rings, and either someone answers or the line goes dead. If no one answers, they pull out their personal phone, find the resident's number in their notebook, and call. The resident may or may not pick up. The visitor waits.
This sequence repeats forty to a hundred times a shift in a busy society. The errors compound. The register entry is illegible by the end of the week. The intercom's flat A-301 actually rings B-301 because someone wired it wrong years ago. The notebook has the number for the previous tenant. The guard makes a judgment call to let the visitor in, or to make them wait, or to call somebody else. None of this is captured anywhere a manager can see.
The guard is not the problem. The guard is doing a difficult job with the tools the society has given them.
What we tried not to do
When we started building UnitSync, the obvious answer for the gate was: give the guard an app. Native, fast, designed for low-end Android, with offline support and a barcode scanner and the works. That is what most platforms do. It is what we assumed we would do.
We changed our mind for three reasons.
The first is that guards rotate. A society employs four or five guards across shifts, but the actual people change every few months — sick days, leave, contract switches between security agencies. Whatever you install on the guard phone has to survive that rotation. An APK does not. A bookmark does.
The second is that guard phones are not always the guards' phones. Some societies hand out a shared phone for the gate. Some agencies issue handsets. Some guards use their personal device. An app that requires installation is a different experience on each of those, with different permissions, different storage limits, different versions. A browser is the same everywhere.
The third is that an app store is a hostile environment for an enterprise tool. Updates depend on Google's review queue. Permissions get revoked when Android does a security update. The version drift between guard phones across a single society became its own support problem. The browser, by contrast, ships from our servers — every guard sees the latest version every time they open the page.
So we built the Guard PWA. Three screens — Home, New Visitor, Code Lookup. It runs on any Android handset with a modern browser, which by 2026 means anything sold in the last six years. The guard saves it as a bookmark on the home screen. They open it like any other app. They never see the word "browser".
What changes when the guard becomes a sensor
Once the guard's tool is connected to the same system as the resident and the manager, the gate becomes a data layer. Every entry, every approval, every fast-tracked delivery is timestamped, attributed, and visible. The notebook of phone numbers becomes redundant — the resident's WhatsApp does not need a phone number lookup, because the platform already knows who lives where.
The intercom becomes redundant too. Instead of a one-to-one phone line that may or may not be answered, every adult in the flat gets the approval card simultaneously. First tap wins. The resident who is in the kitchen and the spouse who is at work both saw the request; whoever is closer to a phone responds. If neither does, the platform records the timeout and surfaces it to the manager.
The paper register stops being the system of record. It becomes, at most, a redundant backup that the manager can confirm against the digital log. Many societies stop keeping it within a month.
What the manager sees
For the society manager, the change is less about workflow and more about visibility. They had no way to know how many visitors came yesterday, or how often residents respond, or which guards are spending more time at the gate versus the corridor. Now they do. The admin console shows the live log, the seven-day trend, the residents whose approvals consistently time out. None of this is novel as a dashboard — it is novel as a thing that exists at all for a society manager who, until recently, was working from the same paper register the guard was.
The bottleneck at the gate did not move from the guard's phone to a different phone. It dissolved. Whatever happens at the gate now is captured in real time, visible to everyone who needs to see it, and unconnected to whether the guard happened to remember to write it down.
If you are evaluating community software, look at the gate first. Whatever you choose has to make the guard's day better, because if it does not, nothing else in the platform will work. That was the design constraint we started from, and it is the one we keep coming back to.