Real Estate Investment Platform
Problem
Users buy into property partnerships and hold fractional ownership alongside other investors. The domain is unforgiving: ownership shares, partner records, and returns all have to reconcile, and an investor looking at a number expects it to be the same number the back office sees. The interfaces had to make that math visible rather than just display it.
Constraints
Financial data means correctness is not negotiable, and the frontend cannot be the place where a shape assumption silently drifts from the backend. The API was NestJS and evolving in parallel with the UI, so the two had to move together without either blocking the other.
What I chose · Outcome
I worked the API contract from both ends rather than consuming whatever arrived — designing REST and GraphQL shapes with the backend team, then holding those shapes in strict types so a contract change surfaced as a compile error rather than a wrong figure on a dashboard.
- End-to-end type safety across the NestJS boundary — contract drift fails the build, not the balance sheet
- Investment and ownership-share dashboards that reconcile against back-office records rather than approximating them
- Partner-record interfaces handling nested, multi-party ownership structures
- REST and GraphQL contracts designed jointly with the backend team instead of retrofitted client-side