Most property search still works the way it did in 2005. A user picks a suburb, drags a price slider, ticks "3+ bedrooms", and gets 400 results sorted by newest. The search understood the filters. It never understood the buyer.
That gap is what AI property search is actually for. Not chatbots bolted onto a listings page, but a search layer that reads "a quiet three-bed near good schools, walkable to a station, under $900k" and returns twelve properties a human agent would have picked. This piece covers what that system is actually made of, where these projects stall, and how to tell whether yours is working. It is written for the person scoping the build, not the person demoing it.
What goes into an AI property-search system
A production AI property-search experience is more than a keyword filter. The pieces that move the needle:
Semantic and natural-language search. Buyers describe what they want in plain language. Embedding-based search with an LLM query layer translates that intent into structured filters plus ranked results, instead of forcing users into rigid drop-downs. The hard part is not the embedding. It is deciding which parts of the query are hard constraints (budget, bedroom count, suburb) and which are soft preferences (quiet, light-filled, near a park). Treat a hard constraint as soft and you show someone a $1.4m house when they said $900k, and they stop trusting the search immediately.
Listing enrichment. Raw listings are inconsistent and thin. Descriptions are written by hundreds of different agents with different habits. Photos are unlabelled. Enrichment means extracting structured attributes from free text and images so that "north-facing", "renovated kitchen" or "period features" become searchable rather than buried in prose.
Ranking that reflects intent. Relevance in real estate is not one number. A buyer weighs price against commute against school catchment against condition, and the weighting differs per person. Ranking has to combine several signals rather than sort by a single similarity score.
Freshness. Property inventory turns over constantly. An index that lags by a day surfaces properties that are already under offer, which is the fastest way to lose a user's trust.
Where AI property-search projects stall
The demo is easy. A weekend gets you a convincing natural-language search over a few hundred listings. The durable product is a different problem, and it usually fails in the same few places.
Data, not models. This is the big one. Listings arrive in inconsistent formats from different sources, the same property appears three times with different photos and prices, and location and pricing data live in separate systems that disagree. Teams budget for the AI and discover the work is a normalisation and deduplication pipeline with a model on the end. If you are scoping this, assume the data pipeline is the majority of the build, not a preliminary step before the interesting part.
Re-embedding cost at real inventory volume. On a marketplace taking thousands of new listings a month plus constant edits to existing ones, embeddings are not a one-time job. Every price change and description edit is a potential re-index. Teams that treat embedding generation as a setup task rather than an ongoing pipeline get a search that quietly drifts out of date, and the failure is invisible until users complain that results are stale.
Confident wrong answers. An LLM query parser will happily interpret an ambiguous suburb name or invent a constraint the user never gave. In a search over listings, a hallucinated filter does not look like an error. It looks like a short result list, and the user concludes there is nothing available. Constrain the parser to a fixed schema and validate what comes out of it, rather than trusting free-form output.
No fallback path. Semantic search returns nothing useful for a meaningful share of queries, particularly very specific ones and misspelled suburbs. Without a keyword fallback the user hits an empty state and leaves. The best implementations run both and merge.
Fair-housing and disclosure risk. Any ranking that learns from user behaviour can start correlating with protected attributes through proxies like postcode. This is a live legal question in several markets and it belongs in the design conversation, not in a review after launch.
What drives the cost
We are not going to quote a single number, because the range on this work is genuinely wide and the drivers matter more than the figure. What moves it, roughly in order of impact:
- Data condition. Clean, single-source listings sit at the bottom of any range. Multiple feeds needing deduplication and normalisation push the cost up faster than any model choice you will make.
- Inventory volume and churn, which set re-indexing frequency and the infrastructure baseline.
- Whether you need enrichment from photos, which is a separate pipeline from text and often doubles the enrichment scope.
- Ongoing model and infrastructure spend, which is a running cost rather than a build cost, and is the line most first budgets forget entirely.
The useful planning heuristic: assume the data pipeline is the majority of the build and the model work is the minority. Budgets that invert those two are the ones that overrun.
How to tell whether it is working
Most published claims about AI search improvements are unfalsifiable, because almost nobody instruments the before-and-after tightly enough to defend a number. If you are commissioning this work, that is your problem to solve, and it is far cheaper to solve before the build than after.
Decide these before you build, not after:
- A held-out query set. Take a few hundred real searches from your logs, have a human mark which listings should have surfaced, and score against it. Without this you are judging search quality by demo vibes.
- Zero-result and one-result rate. The clearest early signal that a query parser is over-constraining. It usually moves before anything else does.
- Search-to-enquiry rate, not click-through. Clicks go up when results look interesting. Enquiries go up when results are right. Only the second one is worth money.
- Position of the first clicked result. If users consistently click result nine, the ranking is wrong even though the recall is fine.
- Latency at the 95th percentile. An embedding lookup plus an LLM parse plus a rank can quietly reach two seconds, and property buyers refine searches constantly.
Instrument these first and you can prove the system works. Skip them and you will be in the same position we were: confident the search is better, unable to publish a number that proves it.
When AI search is the wrong answer
If your catalogue is small, faceted filters already work and AI search is a worse experience with a higher bill. Under a few thousand listings, a well-built filter UI beats semantic search on both speed and predictability.
If your listing data is poor, fix that first. AI search over bad data produces confidently wrong results, which damages trust faster than no feature at all. The enrichment work usually improves the existing search enough to be worth doing on its own.
And if the real problem is that buyers cannot find anything because you have low inventory, no amount of search sophistication fixes it.
Where AI search does earn its cost is narrower than vendors suggest: large and fast-moving inventory, buyers with fuzzy multi-factor criteria, and listing descriptions rich enough to extract meaning from. If all three are true, it is worth building. If only one is, fix the data and revisit.
