Which gated community management software should a committee actually buy? The feature grid will not tell you — every platform demos a visitor gate pass, a maintenance bill and a notice board, and for forty minutes they all look identical. What separates them is what a demo never shows: how many flats still open the app in month three, whether a guard and an accountant get genuinely different screens, whether you can pull your own ledgers out on demand, who holds the collection account, and what happens on the day you stop paying. Below are twelve things to test while the salesperson is still on the call, plus the commercial questions that decide whether you are buying a tool or renting your own data back.
Adoption is the only score that matters
A platform that a third of flats use is worse than a well-run WhatsApp group, because now the committee maintains both. Every other criterion — dashboards, module count, an app on both stores — is downstream of whether residents open the thing unprompted.
Vendors know this, which is why they quote registered flats. That counts every household that tapped a one-time OTP link on onboarding day, usually because the secretary stood in the lobby and made them. It never goes down, and it tells you nothing.
What to ask instead
- Monthly active flats as a percentage of occupied flats, at month 3 and month 12 — for societies of our size, in our city. Not "users": two family members in one flat are one household.
- How many distinct residents raised a complaint or pre-approved a visitor in the last 30 days at a comparable society?
- What share of collection arrived through the app, versus a bank transfer someone reconciled by hand?
- The secretary's number at a society that downgraded or left. A vendor who cannot name one has either never lost a customer or is not being straight with you.
Then look for the structural adoption killers, which are usually visible in the demo itself. Does approving a visitor require the resident to install an app, or does a WhatsApp or SMS link work? Can a tenant and an owner share one flat record with different permissions? Does onboarding make every household re-enter data the committee already holds? Each of those costs month-three usage, and they compound.
The 12-point checklist to run in the demo
Do not watch a canned walkthrough. Ask for a sandbox seeded with ten of your own flats, real names and real rates, and run these yourself with the treasurer and a guard present. Anything the vendor must "get back to you on" is a no.
| # | Module | Test to run live | Fail signal |
|---|---|---|---|
| 1 | Gate pass | Pre-approve a visitor, then admit them while the resident's phone is switched off. | Entry blocked, or guard must call the flat anyway. |
| 2 | Gate log | Search one vehicle number across six months and export the result. | Search only within a single day, or no export. |
| 3 | Delivery & staff entry | Log a daily maid, a courier and a cab; count the guard's taps for each. | More than four taps for a routine daily-help entry. |
| 4 | Maintenance billing | Run a full cycle for all flats with three different rate heads at once. | Heads must be billed in separate runs, or rates are one global number. |
| 5 | Corrections | Cancel one issued bill and reissue it correctly. | Only fix is deleting the run, or history is edited silently. |
| 6 | Arrears | Age outstandings 30/60/90 days and apply penal interest per your bye-law. | Interest is a flat manual entry, or ageing is a spreadsheet again. |
| 7 | Receipts | Receipt a payment that arrived directly in the society bank account and match it to the bill. | Only in-app payments can be receipted. |
| 8 | Accounting | Produce a trial balance and a head-wise ledger, and export both for the auditor. | "Reports" are only dashboards; no double-entry underneath. |
| 9 | Complaints | Raise one, assign a plumber, breach the SLA, reopen after closure, then report by category. | No assignee, no clock, no reopen, no category report. |
| 10 | Notices & polls | Issue an AGM notice with read tracking, run a poll, export the vote trail. | Notices are a broadcast with no record of who saw it. |
| 11 | Staff & guard app | On a low-end Android phone with weak signal, mark attendance and complete a patrol round. | Guard flow assumes a good phone, good data, or English literacy. |
| 12 | Handover & audit | Remove the outgoing treasurer's access, transfer ownership to the new committee, and show who last edited a bill. | Only the vendor can transfer ownership, or there is no immutable log. |
Test 12 is the one committees skip and later regret. Office-bearers change yearly; if revoking a former treasurer's billing rights needs a support ticket, you have a governance problem in a software costume.
One app for everyone is why adoption dies
A recurring design failure in this category is one app with a role dropdown bolted on. Five constituencies use a society system and want almost nothing in common:
- Residents want four things fast — pay the bill, approve a visitor, raise a complaint, read a notice. Everything else on that screen is noise that costs you usage.
- The committee needs approvals, arrears visibility and escalation — and secretary and treasurer should not hold identical powers.
- The accountant lives in ledgers, vouchers and bank reconciliation, and will abandon anything that cannot export cleanly.
- Guards need a two-tap screen in the local language that works on a cheap phone at 2 a.m., with an offline fallback when the gate loses signal.
- Maintenance staff need a work queue and proof of completion, nothing more.
Ask to see all five interfaces in one session. If the guard screen is just the resident screen with buttons hidden, adoption at the gate — where the system earns or loses trust in week one — will not survive the first busy evening. Our own society product, MyCommunity, ships separate role apps for residents, committee, accountants, guards and maintenance for exactly this reason. If guarding is the bigger half of your problem — multiple gates, shift rosters, patrol proof, payroll from attendance — evaluate a dedicated system such as Ctrl Room alongside the community platform.
The export test, the exit, and the DPDP question
Demand the export while you are still evaluating
During the trial — not after signing — demand a complete export of everything you have entered: member register, bills, receipts, ledgers, complaints with their history, gate logs. Insist on CSV or Excel for anything numeric, PDF only for what is already a document. "We can arrange that if you ever leave" means the export does not exist yet; a charge for it is the price of leaving, quoted early.
Judge the export on shape, not on the fact that a file arrived. Do ledger rows carry flat number, head, date, voucher reference and running balance? Does the complaint export reconcile against the dashboard? A dump with no keys is not portability.
What happens on the day you stop paying
Get this in the agreement in plain words: how long the account stays readable after non-payment, whether export still works in that window, how long backups are kept, and whether data is deleted on request. Free tiers need the same clause — free is a price, not a promise.
Who is the data fiduciary?
A society platform holds resident names, flat and vehicle numbers, phone numbers, domestic staff identity records, visitor movement histories and sometimes photographs — a serious personal-data footprint by any reading. Under India's Digital Personal Data Protection Act, 2023, the entity that determines the purpose and means of processing is the data fiduciary and carries the compliance obligations; a vendor processing on its instructions is a data processor. In almost every society deployment the association is the fiduciary and the vendor the processor — but that allocation, along with breach notification, sub-processing, retention and deletion, belongs in the contract rather than in an assumption. A supplier who has never been asked to state its position in writing is itself a data point.
Follow the money before you follow the features
Payment plumbing is where a cheap platform turns expensive. Six questions:
- Whose account collects? Does maintenance land in the society's own bank account, or in the vendor's pooled account for later settlement? Pooling is normal for aggregators, but the committee answers to members for float it does not control.
- Settlement timing. T+1, T+2, or "within a week"? Get it in writing, including year end.
- Who pays the convenience fee? Residents, or the association out of the budget? If it is passed on, expect a share of them to keep paying by direct transfer — so reconciliation (test 7) must be excellent.
- Receipt numbering. Do app receipts share one statutory series with manual receipts, or does the auditor now face two books?
- Failed and duplicate payments. Who chases a debit that never reached the society, and in what turnaround?
- Refunds. Can an overpayment be carried to the next cycle without editing a closed period?
Bye-law fit: corpus, sinking fund and per-square-foot billing
Most software here is built around a single "maintenance" figure per flat — fine until the auditor asks why the sinking fund is not separable. Co-operative housing society bye-laws generally require certain collections to be held and reported as distinct funds. Test these specifically:
- Are corpus, sinking fund and major repair fund separate heads with their own opening balances, ledgers and year-end reporting — or tags on one pot?
- Can you bill per square foot for some heads and per flat for others in one cycle? Service charges are commonly equal per flat while sinking-fund contributions follow area.
- Non-occupancy charges for tenanted flats, parking per bay, water on a meter reading, and special levies with instalment plans.
- Part-payment allocation: when a member pays half, is it applied oldest-arrear-first, head-wise, or by a rule you choose? That setting changes every arrears report you present at an AGM.
If the platform cannot express your bye-law arithmetic, you will either amend your practice to suit the software or keep a shadow spreadsheet — and the shadow spreadsheet always wins. Where the gap is structural, a configured or custom build through a business software partner beats bending your accounts around someone else's data model.
Run one billing cycle in parallel before you switch
Do not migrate on a promise. Run one full month on both the old method and the new platform, then compare with the treasurer, line by line:
- Total billed, rupee for rupee, and every flat where the two differ — each variance has a cause and you must name it.
- Receipt count and total collected, including payments that arrived outside the app.
- Arrears carried forward per flat, and the interest computed on them.
- Whether ledger totals tie to the trial balance the accountant will sign.
- Treasurer hours spent — the honest number, including chasing residents through the new flow.
- Billing disputes raised during the parallel month, and how many were the software's fault.
A parallel cycle costs one month of double entry, and it surfaces the mismatches no reference call will.
When a society platform is the wrong answer
Said plainly: a small society may not need any of this. Under roughly thirty flats, with no employed staff, no guard on the gate and no lift or STP contracts, a shared drive with one maintained spreadsheet, a UPI ID, a WhatsApp group and a disciplined treasurer will serve you honestly — a platform mostly adds a login people forget. This software earns its keep by coordinating employed people, producing an audit trail across changing committees and making arrears visible. Without those pressures you are buying overhead.
Two more cases. When the real problem is that members are not paying: software makes arrears visible, it does not collect them, and no dashboard replaces a committee willing to have an uncomfortable conversation. And when your accountant already runs proper books in a package the platform cannot export into — you end up with two ledgers and one truth, and the truth will not be in the new system.
What to do next
Run the twelve tests in one sitting with the treasurer and a guard present, demand the full export before any signature, and settle the payment-flow and data-fiduciary questions in the contract. Then run one billing cycle in parallel. Survive all four and adoption is the only risk left — and adoption is decided by whether residents can approve a visitor and pay a bill without a fight.
We build and run MyCommunity ourselves, free to use, with separate role apps for residents, committee, accountants, guards and maintenance staff — so treat this checklist as the one we expect to be tested against, not a sales grid. It sits alongside the rest of our product line for real estate, education and field operations.
If you want a second opinion on a shortlist you are already evaluating, or on whether your society is better served by configuration than a subscription, send us the specifics — a senior engineer, not a sales bot, replies within 24 hours.
Running a gated community?
MyCommunity handles visitor gate passes, maintenance billing, complaints and notices — with separate apps for residents, the committee, accountants and guards.