Build story

Lotlytics — Real Estate Analytics SaaS

Investor-grade market analytics across 939 US markets and 21,000+ ZIP codes, designed, built, and operated solo.

2024–PresentLive · lotlytics.usNext.js 16TypeScriptFastAPIPostgreSQLTailwindCSSVercel

The problem

Real-estate investors comparing markets work from scattered, stale data: prices in one tool, rents in another, crime statistics in a government portal, none agreeing on a market's boundaries or how current the numbers are. Comparing two cities honestly means a dozen browser tabs and a spreadsheet.

I built Lotlytics to collapse that into one place: investor-grade analytics across 939 US markets and 21,000+ ZIP codes, every answer drawn from the same reconciled dataset. Solo-built, 2024 to present, live at lotlytics.us.

Building the data layer

Underneath, this is a data-reconciliation problem with a UI on top. Lotlytics aggregates nine-plus sources — including FBI crime trend data via the Crime Data Explorer API — and each arrives with its own geography and its own update cadence: some report by metro, some by county, some by ZIP. Folding them into one PostgreSQL model that answers consistently at both the market and ZIP level was most of the engineering.

The stack splits along that line: a FastAPI service handles ingestion and serves data; a Next.js 16 and TypeScript front end on Vercel, styled with TailwindCSS, renders it. Uptime monitoring watches both — the on-call rotation is me.

Turning data into distribution

With 21,000+ geographies in the database, every one can be a page. An automated SEO pipeline generates city and market report pages programmatically from the live data — no CMS, no hand-written posts. Those pages are the marketing budget.

Monetization layers on top. The free tier shows major metros; the paid Investor plan unlocks the market finder, head-to-head comparisons, and portfolio analysis. A public developer API with key-based auth and rate limiting opens a second surface, and insurance and finance affiliate integrations add revenue that doesn't depend on subscriptions. Watchlists enforce tier-aware limits, so the free/paid boundary stays consistent across every feature.

Tradeoffs

Programmatic SEO pages instead of hand-written content

One person can't write 21,000 city pages. The risk is thin content, so every generated page is built around real data for its geography — it earns its ranking with the numbers, not the prose.

A separate FastAPI backend instead of Next.js-only

Ingesting and reconciling nine-plus sources is Python-shaped batch work, and the public API needed its own auth, rate limiting, and deploy cadence. The cost is a second service to run; the win is a data layer that doesn't move when the website does.

A deliberately narrow free tier — major metros only

Give away everything and there's nothing to convert to; give away nothing and the programmatic pages are hollow. Major metros are the compromise: real enough to rank and build trust, while the tools investors pay for stay behind the Investor plan.

Where it stands

›939 US markets and 21,000+ ZIP codes served from one PostgreSQL model reconciling 9+ data sources
›Programmatic market-report pages published automatically
›Tiered subscriptions and affiliate revenue live, public developer API shipped
›Uptime-monitored in production at lotlytics.us, solo-built and operated since 2024

What I'd do differently

I'd design the geography model before ingesting the first source. Every source has its own idea of what a place is, and reconciliation — not features — was the hardest, least visible work; better schema decisions up front would have made each new source cheaper to add. I'd also make plan entitlements first-class schema from day one: tier-aware limits touch more of the codebase than any single feature, and they're far easier to design in than to bolt on.

Email me More projects