Sit down with a society manager who has been running a community management app for a year, and the conversation always reaches the same place. The product works. The features are fine. The price is reasonable. But only half the residents are on it, and the other half is the half that matters most — the elderly residents whose visitors arrive unannounced, the tenants who move in and out, the family members who answer the door when the owner is at work.
This is not a marketing problem. It is a structural one.
Where the ceiling comes from
Adoption in resident-facing software is not a single decision. It is a chain of decisions, and the chain breaks at every link.
A resident has to be told the platform exists. They have to find it in the right app store — Android or iOS, with the right name, in the right country. They have to install it. They have to grant permissions. They have to verify a phone number. They have to find their society in a list. They have to wait for the manager to approve them. They have to remember the password they just set. They have to keep the app installed when their phone runs low on storage. They have to remember to open it when something happens at the gate.
Each link in that chain has a drop-off rate. Some are small — most people who hit "install" finish the install. Some are large — many people who install never come back after the first week. Multiply the survival rates and you get something that hovers around 40 to 60 percent of residents actively using the platform after a few months. The exact number varies; the order of magnitude does not.
That ceiling is not a defect of any one product. It is the cost of asking people to add a new app to their life.
What residents are actually being asked
Step back from the product and look at what is being asked of a resident. They live in a flat. Visitors come to that flat. Sometimes they want to approve them, sometimes they want a delivery to be let in without being bothered, sometimes they want a cab driver waved through. None of this is software. It is the texture of living somewhere.
When a society introduces an app, the resident is being asked to translate that texture into a different surface. They were already managing visitors — through phone calls, through the watchman ringing the bell, through a shouted reply from the kitchen. Now they are being asked to do it through an app they did not choose, that competes for attention with WhatsApp, Instagram, banking, work, and everything else.
The residents who say yes to this are the ones for whom installing an app is a small ask. Younger, technically comfortable, already in the habit of trying new tools. The residents who say no are not anti-technology. They are people for whom the cost of one more app is greater than the benefit. That set tends to include the elderly, the very busy, the recently moved, and the residents who travel.
The shape of the answer
If the chain of decisions is the problem, the answer has to be a chain with fewer links. WhatsApp is already on the phone. The resident already opens it dozens of times a day. The notification already arrives in a familiar place. There is no install, no account, no password.
That is the entire pitch. When a visitor arrives, the resident gets a message in WhatsApp from UnitSync — a verified business account. They tap Approve or Deny. The gate opens. There was nothing to learn.
What happens to the ceiling? It does not disappear, but it shifts. The residents who would not install an app will respond to a WhatsApp message, because they were going to read WhatsApp anyway. The elderly residents who never finished the onboarding flow are now in the system from the first message. The tenants who joined three months in are not behind on anything — they were always reachable.
The number we are designing for is 85 percent or more. Not because the software is better, but because the question being asked of the resident is smaller.
What this does not fix
Being WhatsApp-native is not free. The vocabulary is constrained — buttons, lists, structured Flows, not arbitrary screens. Some workflows that are natural in a dedicated app become awkward over chat, and we will not pretend otherwise. The admin console for managers stays in the browser, where richer interfaces belong. The Guard PWA stays in the browser, where speed and screen size matter more than chat.
The split is deliberate. The resident — the user with the highest cost of switching surfaces and the lowest patience for it — gets the surface they were already on. The professional users — managers and guards — get a surface designed for their job.
What this changes for the manager
If you are running a society, the practical change is that adoption stops being an open project. You do not need to chase residents to install something. You announce that UnitSync is live, and the next time a guest arrives at the gate the resident discovers the experience inside an app they already use. That is the entire onboarding.
You also stop running two systems. The reason most societies still keep the watchman calling residents on the phone is that not enough residents are on the platform to make the platform sufficient. When the platform reaches the residents who would never install an app, the phone call becomes the exception instead of the rule.
The ceiling has not gone away. It has moved high enough that you stop noticing it.