Case study
BigTown
Estate community management and billing system — 13 distinct roles, property-level dues, visitor QR/PIN gate security, announcements, meetings, maintenance, and a full audit log. 32 database tables.
- My role
- Product Designer + Full-Stack Developer
- Category
- PropTech / Community SaaS
- Roles
- 13 distinct user roles
- Database
- 32 tables, estate-scoped RLS
The design problem
One system, thirteen distinct roles
Managing an estate involves radically different jobs: a resident needs to pay dues and request a visitor pass; a security officer needs to verify a QR code at a gate; an estate manager needs to see all properties and outstanding payments; a super admin needs multi-estate oversight. Every navigation structure, every data view, every permission was designed with role isolation as the primary constraint — not an afterthought.
Visitor security
Security-first gate access
Residents generate one-time visitor passes — hashed codes shown exactly once and stored hashed. Security officers see only a verification interface — no financial data, no resident information. Gate admission is a server-side transaction that checks estate membership, approval status, time window, revocation, and prior use before recording an admit or deny. The audit trail is immutable.
Financial architecture
Property-level dues, not resident-level
Dues are attached to properties, not residents. This correctly handles the reality that owners, tenants, and caretakers change over time while the property and its obligations remain. Annual Levy, Security Levy, and Development Levy each have separate line items, with partial payment support, installment windows, late fee logic, and immutable receipts.
Built with