Real Estate Operations Platform
Built for a U.S. real estate investment operator running multiple properties, across four connected problems: evaluating deals, inspecting properties, tracking what's actually being spent on each one, and turning inbound sellers into a working pipeline. Not four separate tools — one operator's business, understood well enough to know where each piece belongs.
- ROLE
- System design across evaluation, inspection, accounting, and lead intake
- TOOLS
- ChatGPT · Claude · Lovable · VS Code · Git/GitHub
Four real jobs, run out of spreadsheets and disconnected tools.
Evaluating a deal, walking a property, tracking a renovation expense, and qualifying a seller lead were each happening somewhere — a spreadsheet here, a form there, a folder of receipts nobody had sorted by property. None of it was connected, so the same operator kept re-deriving numbers by hand: which property a cost belonged to, whether a deal actually cleared its target return, which inbound lead was worth a call. This case study covers the four systems built to close that gap, at four different stages of maturity — described honestly below.
One operator's business, split into four systems that talk to each other.
Real Estate OS is the hub — property records, financial modeling, and lead capture live there. The other three were designed to connect into it rather than stand alone: an inspection workflow that feeds observations back to a property record, a ledger that assigns every expense to the right property, and a lead engine that hands qualified sellers into the same pipeline. Two of the four are running in real use; two are still architecture and prototype — that split is called out on each one below rather than smoothed over.
Real Estate OS
One operating environment for property and deal records, purchase-price assumptions, NOI and cap-rate calculations, projected cash flow, and investment metrics — plus configurable landing and intent pages with attribution tracking and automated sitemap and structured metadata. It started as a Lovable prototype and grew into a more structured development environment as the product's logic got more complex than a prototype could hold.
Mobile AI Property Inspector
A designed mobile workflow: an investor or broker photographs a property — roofing, flooring, kitchens, bathrooms, electrical, plumbing, structural, exterior — and an AI layer is envisioned to turn those photos into a structured read on each area, feeding straight back into the property record in Real Estate OS instead of living as its own disconnected app. This is a prototype and product-design concept, not a shipped tool — it isn't live yet, and that's stated plainly rather than implied otherwise.
Property Ledger AI
Expenses arrive from bank and credit card statements, hardware-store receipts, and contractor invoices, and the real question was never just how much was spent — it's which property it belongs to and what kind of work it paid for. The domain architecture is built: properties, organizations, documents, receipts, financial records, classifications, integrations, and reporting, with repository and service layers for portfolio management, job costing, document processing, receipt processing, and review — over 100 files of TypeScript/TSX domain and service code. The AI ingestion workflow below is the intended flow the architecture was built for; it's still in development, not fully live end-to-end.
Seller Lead Engine
An automated seller-lead funnel starting from a Google ad: a seller enters their property address, explains their situation, and leaves contact info, with attribution captured on the way in. From there the lead enters a structured acquisition pipeline with real stages, backed by the same configurable landing pages, intent-based routes, and investment calculations Real Estate OS runs on. The functional pieces of this one are built and working.
A traditional build ships exactly what's asked for. This started with how the business actually runs.
A contract developer given four separate requests would have shipped four separate tools, each doing exactly what its spec said and nothing more. Instead the starting point was understanding the business itself: how a deal actually gets evaluated, why accounting has to happen by property and not by total spend, what makes one seller lead worth calling and another not. Only after that did it make sense to decide where AI reasoning belongs, where structured data belongs, and where a human review step has to stay — one connected system with four working parts, rather than four tools that don't know about each other. Two of those parts, the mobile inspector and the ledger's ingestion pipeline, are honestly still prototype and in-progress work, not finished products — that's the accurate state of them today, not a caveat to gloss over. The workflows above are described at a high level deliberately — happy to walk through the details on a call.
Running a real estate operation across spreadsheets and disconnected tools?
Tell us what's scattered today — deal evaluation, inspections, expense tracking, or lead intake — and we'll map what a practical implementation could look like.