How We Built India's First Natural Language Property Search Engine (Tech Stack + Architecture)

When we started AI-Ghar, India's property search was stuck in the filter dropdown era. Every portal worked the same way: pick city, pick locality, pick price range, get 500 results. Our goal was different: describe what you want in plain English, get 5 perfect results in under 4 seconds.

The Problem We Solved (And Why It Was Hard)

Natural language property matching is harder than it sounds. '3BHK near Kondapur under ₹1.2 crore, vaastu OK, possession in 2 years' contains location intent, budget ceiling, lifestyle preference, and a time constraint — all in one sentence. And every buyer phrases it differently. '₹1.2 crore', 'within 1.2 cr', 'budget of 120 lakhs', and 'not more than ₹1.2L' all mean the same thing and must be parsed identically.

Tech Stack Overview

• ✓Frontend: Next.js 15 (App Router) + TypeScript — Server Components for SEO, Client Components for interactivity
• ✓Styling: Tailwind CSS v4 — utility-first with custom design tokens
• ✓State management: Zustand — lightweight, no boilerplate
• ✓AI layer: Large language model for natural language extraction + custom scoring engine
• ✓Data pipeline: RERA data ingestion + builder project normalization layer
• ✓Infrastructure: Vercel Edge Network for <100ms global TTFB
• ✓Analytics: Custom event tracking for match quality feedback loop

The Query Processing Pipeline

When a user submits a natural language query, it goes through 4 stages: (1) Entity Extraction — the AI parses configuration, location, budget, timeline, and lifestyle signals from the raw text. (2) Normalisation — extracted values are mapped to our canonical property schema. (3) Scoring — all 500+ projects are scored against the extracted requirements using the 6-dimension algorithm. (4) Ranking — results are sorted by weighted composite score and returned with per-dimension breakdowns.

The 6-Dimension Matching Algorithm

• ✓Location Score (30% weight): Straight-line distance from target area, connectivity to key IT hubs, metro proximity
• ✓Budget Score (25% weight): All-in price fit against budget ceiling — includes floor rise, parking, GST, registration estimate
• ✓Configuration Score (20% weight): Exact BHK match, carpet area range, bathroom count
• ✓Timeline Score (15% weight): Possession date vs buyer's stated constraint — penalises overdue projects
• ✓Amenities Score (7% weight): Gym, pool, children's area, power backup — matched against stated and inferred preferences
• ✓Builder Quality Score (3% weight): RERA compliance, past project delivery record, current construction pace index

How We Achieve 3.2-Second Search Results

The key insight: the scoring computation is embarrassingly parallel. We score all 500+ projects simultaneously rather than sequentially. Combined with aggressive caching of static project data (refreshed nightly from RERA feeds), the expensive LLM call (entity extraction) is the only dynamic step — and that's where we spend most of our optimisation effort.

The Feedback Loop That Drives 98.4% Accuracy

After every search, we ask: 'Did the top result match what you wanted?' This binary signal — combined with click patterns, time-on-result, and return searches — feeds back into our scoring weights monthly. The model continuously improves. 98.4% is not a one-time number; it's a floor that keeps rising as more buyers use the platform.

TypeScript Challenges: India-Specific Property Data

India's property market has data quirks you don't find elsewhere. Prices are sometimes quoted in lakhs, sometimes crores, sometimes per sqft, sometimes total. Area is sometimes carpet, sometimes built-up, sometimes super built-up — and the loading (ratio between them) varies by 20–40% depending on the builder. We built a strict TypeScript schema layer that normalises all of this at ingestion time, so the scoring engine always operates on clean, consistent data.