Oasis

Inspiration

Houston has some of the highest office vacancy in the country, and everyone's heard the pitch about converting empty offices into apartments. What's missing is the actual analysis — a real building's floor plate has a specific shape, specific CoStar financials, and specific code requirements, and none of that gets checked by a one-line headline about "office-to-residential conversion." We wanted to build the thing that actually checks it, building by building, floor by floor, with real numbers — not a generic calculator that pretends every building is the same rectangle.

What it does

For any real Houston office building, Oasis pulls the real aerial footprint from Vexcel, scales it to the real square footage CoStar has on record, and slices it into real apartment-sized units — studios, one-beds, two-beds — filtered against real minimum size standards, not just divided evenly. It then prices the conversion using real nearby apartment rent comps, a real cap rate from an actual nearby sale when one exists, and a real operating-expense share pulled from actual Houston multifamily sales, not a flat assumed margin. On top of that: real legal and building-code checks (zoning, parking, the actual IBC occupancy-change and sprinkler trigger, a real Fair Housing Act accessibility check against real elevator data), a live Claude agent that decides which checks to run and writes its own verdict, and a multi-agent "boardroom" where a structural engineer, a city planner, and a market analyst debate the real numbers for that specific building.

We ran it blind across 35 real Houston office buildings — not hand-picked — to prove it generalizes, not just performs well on buildings we tuned it against.

How we built it

The geometry layer buffers a building's real perimeter inward by the standard 45-foot window-to-core distance used in commercial real estate, and walks each wall separately to slice unit-width strips from what's left — respecting real corners instead of cutting across them. The value layer reads CoStar's real lease, sale, and apartment datasets directly and prices the conversion as net income divided by a real cap rate, after a real construction-cost and compliance-fee deduction. An anomaly detector, trained on the real population of cap rates and rents across the entire dataset (not a hand-picked threshold), flags anything that falls outside the real citywide range before it ever reaches a verdict. A Flask backend ties it together; the frontend is a single-page 3D map interface with a live floor-by-floor breakdown, a generated tentative floor plan, and the agent boardroom.

Challenges we ran into

The data had real gaps and real quirks that don't show up until you actually check the raw records instead of trusting the schema. CoStar stores cap rates as plain percentages, not fractions — an early version skipped that conversion and silently produced a 525% cap rate on a real property. The "obvious" vacancy field in the apartment dataset is null for every single record in the kit; the real, populated field has a different name entirely, found only on a second, more careful pass through the schema. A floating-point precision issue in the geometry library, after enough chained polygon operations, produced a unit that was technically a "valid" shape but rendered entirely outside its own building — caught by checking containment directly with real intersection math, not by eyeballing the picture.

Midway through, we also found that our own pricing formula never deducted operating expenses from rental income at all — effectively assuming every dollar of rent converts to profit. Replacing it with a real NOI-based formula, averaged from actual nearby comps, was more financially honest, but it meant every one of our demo buildings flipped from a mix of outcomes to uniformly not-feasible under the more complete math, a real, humbling result that forced us to re-pick which buildings actually tell an honest story.

What we learned

The gap between "the schema says this field exists" and "this field is actually populated and means what you think it means" is enormous, and it only closes by checking the raw data directly, every time, instead of trusting that a clean-looking API implies clean underlying data. We also learned that a stricter, more honest methodology can look worse before it looks better the version of this project with uniformly bad news is more trustworthy than the earlier version with a nicer-looking spread of outcomes, because the earlier version was quietly wrong about operating costs.