LeaseLens

Inspiration

We wanted to build a housing decision-support tool that did not force renters, landlords, and investors into completely separate workflows. Most housing platforms either focus on browsing listings or give limited market information, but they do not help users compare opportunities in a way that feels structured, explainable, and practical.

Our initial version started as a renter and landlord prototype, but the project became much stronger once we shifted toward real active Irvine listings instead of a purely hypothetical dataset. That pushed us to build something more credible and more useful.

What it does

LeaseLens helps users evaluate real Irvine listings in three different ways:

Renter mode lets users search, filter, and compare active listings by list price, modeled rent, estimated gross yield, bedrooms, property type, and days on market.
Landlord mode lets users select a single listing and review an explainable listing score built from real listing inputs plus modeled rent.
Investor mode ranks active Irvine listings and helps users sort and filter for yield, market speed, price, and property type.

Instead of treating housing data as just a list of properties, LeaseLens turns it into a decision workflow.

How we built it

We built LeaseLens with a React + Vite frontend and a FastAPI backend.

On the backend, we integrated:

real active Irvine listing data
a rent prediction model
derived calculations such as estimated gross yield
an explainable landlord scoring system

On the frontend, we created three separate but connected user experiences that all run on the same dataset. We redesigned renter mode to work better with real inventory by adding filters and a smaller comparison workflow, kept landlord mode focused on single-listing evaluation, and expanded investor mode into a ranked opportunity board.

We also rewrote the project structure and documentation so the app behavior, data flow, and setup all matched the real product state.

Challenges we ran into

One of our biggest challenges was moving from a demo prototype to a workflow based on real listings. The original app used hypothetical property records and simulated trend data, but our later pipeline used actual Irvine inventory. That created inconsistencies between the frontend and backend that we had to resolve.

We also ran into challenges integrating the rent model into a live backend. Loading a trained model was only part of the problem; we also had to make sure the runtime data and feature handling matched the model requirements closely enough for inference to work correctly.

Another challenge was UX overload. Showing a large number of real listings at once made renter mode harder to use, so we had to rethink that interface and reduce the amount of information shown at once.

Accomplishments that we're proud of

We are proud that we moved the project beyond a static hackathon demo and made it operate on real active Irvine listing data.

We are also proud that:

all three product modes now share the same real listing source
the app gives users explainable outputs instead of opaque recommendations
renter mode became much more usable after the filter-and-compare redesign
landlord and investor workflows now feel like distinct tools built on top of the same underlying data

Most importantly, we turned a prototype with hypothetical data into something that feels much closer to a real decision-support product.

What we learned

We learned that real data changes everything. It affects not just the backend and model integration, but also the product design, the API contracts, and the way users need to navigate the app.

We also learned that predictive features need careful framing. It is not enough to generate a score or a rent estimate; users need to understand what is factual, what is modeled, and how the app arrived at its outputs.

On the engineering side, we learned a lot about keeping frontend and backend contracts aligned while rapidly evolving the product.