Choosing society software is a committee decision that outlives the committee: whatever you pick, residents will live in it daily and the next committee will inherit it. This is the checklist we recommend committees run every vendor through, including us. Score each item yes or no in the demo; do not accept "on the roadmap" as a yes.
1. Who pays, and how?
If the app is free or nearly free, ask how the vendor earns. The common answer is advertising and cross-selling to your residents: paint, loans, insurance, groceries. That has two costs the brochure never shows: your residents' attention and their data become the product, and the app fills with noise that older residents cannot navigate. A transparent per-flat subscription is the honest model; it keeps the vendor working for the society, not for advertisers.
2. Can every generation in the building actually use it?
Ask for the phone in the demo, then hand it to the oldest committee member present. Can they approve a visitor unaided, first try? Half a society's residents are not 30-year-olds; software that only the young can use pushes everyone else back to phone calls and paper, and the society ends up running two systems.
3. Does it enforce your bye-laws, or its own defaults?
Every registered society runs on its own bye-laws: booking charges, deposits, notice periods, billing bases, penalty rules. Most software ships one hardcoded workflow and asks your society to bend around it. Test with your real documents: bring one bye-law clause and one recent bill to the demo, and ask the vendor to configure both, live. If charges, deposits and notice periods cannot follow your registered clauses, the committee will spend every month explaining discrepancies.
4. Will the books survive an audit?
- Is the accounting double-entry, with a trial balance that foots to zero at any moment?
- Does every invoice show its own math (rate, area, GST behaviour per member)?
- Are member dues tracked per flat with running balances, not spreadsheets on the side?
- Can the auditor get statements without the vendor's help?
Billing apps that are not accounting systems create a year-end scramble; the treasurer re-keys everything into Tally and the audit takes months.
5. What does onboarding actually involve?
"Self-serve setup" usually means the committee does the data entry: every flat, every resident, every opening balance. Ask instead: who loads our registers? Who maps residents to flats? Who configures our charges? White-glove onboarding, where the vendor does this work and the society just verifies it, is the difference between going live in days and abandoning the rollout half-done.
6. The demo tests that expose everything
- Approve a visitor with a photo, end to end, in under ten seconds.
- Generate one month's invoices and trace a single flat's bill to its rate and area.
- Book an amenity and check the charge, GST and deposit against your bye-laws.
- Ask to see the trial balance mid-month.
- Hand the phone to an elder for the visitor approval.
Ads-free subscription, designed for every generation, your registered bye-laws as the app's actual configuration, double-entry books with a live trial balance, and white-glove onboarding measured in days. We built the product to pass this checklist because it is the checklist we believe committees should be running.
Common questions
Should we pilot with one tower first?
Gate and billing systems work society-wide or not at all: a half-society pilot creates two systems at the gate. Better: a full switch with a defined 60-day review clause in the agreement.
What notice period should the contract have?
Look for annual terms with your data exportable at any time: registers, ledgers and dues statements in standard formats. A vendor confident in the product never holds data hostage.