Smart Property & Community

Context

One residential community has at least three kinds of people: owners, family members, tenants. They see different things — an owner sees property and fees, a family member can open doors but cannot pay, a tenant has rights only while the lease runs. Above that, the platform serves several property companies and projects, and data must not leak between them.

Identity matrix

Layer	Identity	Typical rights
Resident	Owner	See unit and bills, pay, invite visitors, open doors, file repairs
Resident	Family member	Open doors, read notices; cannot change the unit or pay
Resident	Tenant	Open doors and file repairs within the lease term, expiring automatically
Console	Super admin	Platform-level configuration and troubleshooting across tenants
Console	Operations	Review and content within assigned tenants
Console	Tenant admin	Units, people, fees and devices of their own tenant
Console	Tenant user	Day-to-day operations within the tenant, granted by menu

Whether a record is visible is decided by four dimensions at once — identity type × role × app center × tenant. The model is enforced in the API, not by hiding buttons: the frontend decides whether an entry point appears, the backend decides whether the data can be fetched.

The loop

Unit binding → Certification review → Fee payment
     │                 │                  │
     ├─ Members        ├─ Owner / tenant  ├─ Property fee
     └─ Multiple units └─ Re-upload docs  └─ Space-management fee
                                            │
Visitor invitation → Door opening → Repair / inspection → Records

Almost every daily property action leaves a record: who certified when, which unit is in arrears, who approved a visitor, which door opening failed.

What I worked on

Identity and tenancy

Two account systems run in parallel: console accounts (super admin / operations / tenant admin / tenant user) and resident accounts (owner / member / tenant). Both log in by phone number, and early on the same number could overwrite itself across the two domains.

I made phone numbers unique per domain and hardened the login path, then constrained cross-tenant and cross-level queries and operations — a tenant admin sees only their own tenant’s users, and cross-level operations are refused.

Fees

Parking-space fees had no resident-facing entry: you paid offline or the console collected on your behalf. I added the mini-program path — choose a space → see arrears → pay → callback settles it — with payment records surfaced on the console.

Certification

Owner and tenant certification require property documents or lease contracts, reviewed by the property manager. The trap is that incomplete material is the norm: some fields must be optional, otherwise a null lands in the database and blocks the rest of the flow. I adjusted validation and persistence so only the genuinely required fields are mandatory.

Engineering notes

• Four-dimensional access control: identity type × role × app center × tenant, all four deciding visibility
• Two account systems, no contamination: domain-scoped phone uniqueness and isolated login paths
• Traceable states: certification, payment and door opening all leave records for later verification
• Identity switching: one WeChat account can bind both owner and tenant identities, with menus and data trimmed per identity

Team and scope

The team owns community and unit modelling, visitor and access-device integration, repair and inspection flows, and the property console as a whole. I own identity and tenancy validation, the space-fee payment path, and unit binding and certification review on the mini program.