Product area
Resident
The resident lifecycle, from a staged move-in through identity verification to visitor passes, held as one record instead of spread across a property management system and a spreadsheet.
From the running build
The screens.
Captures of the build as it stands. The data in them is a demo dataset, not an operator's.
Residents
The roster, onboarding, verification and documents, so the record of who lives where is one thing.
The resident app
The same platform, from the other side of the door. The digital key, visitor passes, service requests, announcements and a rent statement.
Two of those screens read, and do not write. The rent statement shows what is owed and what has been paid; paying from the app is roadmap, and the payment itself is recorded operator-side today. Bookings list reservations an operator has made, because the capacity claim underneath them is built and no user-facing path calls it yet.
The digital key reads "not set up" and the door list is empty because this build is not connected to a live access-control sync. The unlock itself is proven: it was validated on physical hardware, on a real door, from a real phone.
Status
What is built in Resident, and what is not.
Three states, from the same capability map the platform is governed by. The middle one is the one worth reading.
Shipped
Built, and working in the running build.
- Resident and unit records
- A move-in workflow with staged onboarding: unit confirmation, documents, identity verification, lease, payment and key provisioning
- Visitor invitations and passes
- Identity verification at a data-minimised third-party provider
Partial
Built underneath, and not reachable end to end yet.
- SMS delivery is a no-op in production, so phone verification cannot complete
Roadmap
Not built. Named here so it cannot be implied elsewhere.
- Paying rent from the resident app, which today presents a rent statement that is read only
- Enhanced move-out and renewal lifecycle automation
- Bulk resident import
The rest of the platform