Case study · AI product
LuxList
An AI-native luxury real-estate search built around one question: what if you described the home you wanted the way you’d tell an agent, instead of fighting a wall of filters?
Case study
Search without filters
The wall everyone ships
Every real-estate site has the same control panel: price sliders, bed and bath steppers, a property-type select and a checklist of amenities behind “more filters.” It works, but it makes you translate a fuzzy want (“somewhere with a view, room for the in-laws, not over four million”) into the site’s vocabulary, one widget at a time.
The shift
LuxList deletes the panel. You describe the home out loud, and a Claude model turns the sentence into the same structured query the filters used to build: location, beds, baths, budget, property type and amenities.
The filter wall asks people to think like a database. Natural language lets the database do the thinking.
Then it becomes a conversation
After the first search, the search bar becomes a chat dock. “Just the ones with a pool” narrows the homes already on screen instead of starting over, the way refinement works with a real agent.
Design decision
Results that tell the truth
When someone asks for five bedrooms under four million in a specific town, the perfect matches are often thin. The easy way to fill a page is to quietly relax the constraint that’s hurting you and hope nobody notices. It looks abundant, and it’s dishonest.
Everything you asked for. Shown first, no caveats.
“4 of 5 · no pool,” “$200K over.” The gap is stated, not hidden.
Budget gets special treatment: in-budget homes always lead, and everything else is ordered by how close it sits to your number. Price is the constraint people are most likely to feel misled about, so it’s the one the ranking is most careful with.
AI makes it easy to generate a confident, full-looking screen. The more senior move is making the system admit what it doesn’t have.
Architecture
One AI call at runtime, one at build
Calling an LLM isn’t the interesting part. The design work was deciding where the AI runs, what’s allowed to touch a secret, and how to keep a live AI app instant without a backend to maintain.
At runtime
Exactly one piece of server code runs when someone searches: a Vercel serverless function that proxies a single Claude call and returns structured JSON. The API key never reaches the browser. Filtering and ranking happen client-side.
At build time
Before deploy, a script reads each messy listing description and distills it into a fixed amenity vocabulary, so a search term and a listing speak the same language. It runs once at build, so it costs nothing at runtime and can never slow a search down.
Why there’s no database
The listings are a curated snapshot committed as static JSON. At this size there’s no need for a search backend: the site is instant and cheap to serve, and the only runtime dependency is the one parse call.