Context
A property developer’s relationship with owners does not end at handover — it ends years later, in how the building is run. Yet the tooling handed over is usually nothing: a chat group for announcements, spreadsheets for billing, and a paper book at the guardhouse. The developer takes the reputational damage for a management problem they gave nobody the tools to solve.
What I did
- Built for the three parties who actually use it daily — residents, building management, and the developer — rather than only for the party that signs the contract.
- Covered the unglamorous core first: billing and collections, visitor and access records, facility bookings, announcements. These are the workflows a building fails at.
- Designed for multi-tenancy from the start, because a developer with a dozen projects should not get a dozen deployments.
- Kept the resident app deliberately small. Residents open this software to pay a bill or register a visitor, not to spend time in it.
Outcome
Developers could hand over a working management platform along with the keys, which turns the post-handover years from a reputational risk into a relationship.
What I’d do differently
I would have spent more time with building management before designing the billing flows. We optimised for the resident’s experience and underestimated how much of the product’s value sits with the small team doing collections every month. When that team resists, adoption stalls no matter how good the resident app is.