How natural-language property search beats traditional filters
Filter dropdowns made sense in 2005. They make a lot less sense now.
Open Daft.ie. Click "Search". Tell it you want a 2-bedroom apartment in Dublin 6 between €1,800 and €2,400 with parking and a balcony, available from June, near the Luas Green Line, that allows pets, that's not a basement flat, and that's been listed in the last 7 days.
You'll click 9 dropdowns. None of them know what "near the Luas Green Line" means in their schema. Pets is a checkbox somewhere. "Not a basement flat" doesn't exist as a filter. The "listed in the last 7 days" filter is hidden two pages deep.
You give up. You search by neighborhood and scroll through 200 listings. You miss the one in Rathgar that just hit Daft 12 minutes ago.
Filter UIs lose because the user's intent is richer than the filter schema can express.
This article walks through how HomeScout's natural-language search works under the hood, what it understands, and what it doesn't.
The basic idea
You type what you want in plain English (or Dutch, Portuguese, Spanish, or Hindi, since HomeScout supports five languages):
"Bright 2-bed in Dublin 2 near Google with a balcony, max 2400, pet-friendly"
The system extracts structured filters from the sentence:
- bedrooms: 2
- area: Dublin 2
- max price: €2400
- features: balcony, pet-friendly
- location intent: "near Google" (Silicon Docks area)
- adjective: "bright" (south-facing or large-windowed listings preferred)
Then it searches the unified property database (sourced from Daft.ie, Rent.ie, MyHome.ie, and others) and returns matching results, ranked by how well each property matches the full intent of your sentence, not just the literal filter values.
Why this is harder than it looks
Three things make natural-language search non-trivial in this domain:
Different sources use different schemas. Daft uses 28 fields, Rent.ie uses 19, MyHome uses 22. They don't agree on whether "garden" is a feature or part of the description. Our system unifies them into one canonical schema with disambiguation rules. You don't see this. It just works.
Adjectives are ambiguous. "Bright" could mean south-facing, large-windowed, or just nice. We use a combination of property descriptions, photo orientation, and historical signal data to score whether a listing is likely to feel "bright" to someone walking in.
Location intent is rarely a polygon. "Near Google" doesn't mean within Google's office building. It means: walking distance, near the Luas Red Line that gets you to Silicon Docks, or short cycle. We translate intent like this into a fuzzy ranking layer rather than a hard filter, so a perfect 2-bed apartment 600 metres from Google ranks above a worse one inside the technical "near Google" radius.
What HomeScout's search understands
Tested examples that work today:
- "1-bed in Rathmines under 1700 with a washing machine"
- "Modern 2-bed near Trinity College for two professionals"
- "Pet-friendly 1-bed with parking, anywhere south of the river"
- "Family home in Dublin 6 or 6W, 3+ bedrooms, garden, max 3500"
- "Studio under 1500 in walking distance of the Luas"
- "Quiet 2-bed near Phoenix Park, no shared accommodation"
Things that don't always work yet:
- Multiple budget ranges in one query ("around 1800 but happy to pay up to 2200 for the right place")
- Highly specific architectural features ("Georgian conversion with original sash windows")
- Date ranges that aren't well-defined in listings ("anything coming up in autumn")
When the system doesn't fully understand a query, it shows you exactly what filters it interpreted and what it didn't, in the AI Feedback Card below the results. So you can adjust without starting over.
How the multi-phase response works
When you submit a query, the search streams its work back to you in three phases:
- Understanding. "Parsing your query into filters and intent." 1-2 seconds.
- Finding. "Searching properties across listings." 2-4 seconds.
- Complete. Results with match scores.
This isn't just for show. Streaming the work back makes the system feel responsive even when the underlying search across multiple listing sources takes 6-8 seconds. You see progress instead of a spinner.
Each result card shows:
- Property photos
- Price, bedrooms, location
- A match score (0-100) indicating how well this property fits the full intent of your query
- Specific badges for AI-detected features (pet-friendly, parking, etc.) when the listing source didn't tag them explicitly
- A Value Score (separate feature) telling you whether the price is fair vs the neighborhood baseline
The match score isn't ranked alphabetically or by price. It's ranked by intent fit. A €2,000 property that matches everything in your query beats a €1,800 property that misses the "bright" or "near Luas" parts.
The streaming architecture, briefly
For the technically curious: when you submit a query, your browser hits a Next.js BFF (Backend for Frontend) route, which proxies to a FastAPI backend. The backend uses an LLM to parse your sentence into structured filters plus intent vectors. It then runs a hybrid search: structured filters narrow the candidate set, then a re-ranker scores each candidate against the original intent.
The streaming part happens via Server-Sent Events. The first chunk back is the parsed query (so you can see what was understood). The second chunk is the candidate result list. The third chunk is the re-ranked, scored results.
Suggestion pills: skip thinking entirely
Sometimes you don't want to type. The search bar shows three suggestion pills before you type, like:
- "1-bed under 1800 in Dublin 6"
- "2-bed with parking near Trinity"
- "Pet-friendly studios in the city centre"
Click one, it runs the search. After your first search, the pills change to refinements based on what you searched (smaller area, higher budget, different features). It's faster than re-editing the query box, especially on mobile.
When to use natural language vs filters
Honestly, both have their place.
Natural language wins when:
- You have a multi-criteria query that doesn't map cleanly to filters
- You want to express location intent ("near work", "walking distance to X")
- You're searching on mobile and dropdowns are painful
- You don't know the exact field names in the source schema
Filters win when:
- You want to iterate fast on one variable ("same query, but cheaper")
- You're refining a search you already ran
- You know exactly what you want and the schema supports it
HomeScout supports both. The natural-language input is the default because it gets most users to a useful result faster. The filters are still there for refinement.
Why we built this
Filter UIs were never the right abstraction for property search. They came from e-commerce (where the schema is small and well-defined) and got shoehorned into rentals (where intent is rich and lossy in any structured form).
Talking to the search like you'd talk to a friend who knows Dublin is a much better fit for the actual user task. The system catches up to your intent. You don't translate your needs into the system's schema.
Try it
The natural-language search is included in the free Explorer tier (10 searches per month) and unlimited on the paid HomeScout tier. 7-day free trial, no card required.