How we shipped HomeSearch AI in five months

A public ship date is a forcing function for architecture. It shapes what you can build as much as when you ship, because every option that might not land by the date is gone before you start.

In March 2025, Inside Real Estate acquired ListAssist, a small team with strong natural-language and computer-vision models for property search. Within weeks, the company committed publicly to launching HomeSearch AI across BoldTrail, its agent CRM serving roughly 400,000 agents, and CORE Home, the consumer portal. The date was the summer.

The models were promising. The constraint was the platform around them. Conversational search at production scale needed a search service that could carry classic and AI queries on one contract, an alert pipeline running at 160 million emails a month that understood intent, voice as a first-class input, and a way to keep tuning the system after launch. None of it existed yet.

We took ownership of the engineering. We had already rebuilt CORE Home, so the surfaces, the data shapes, and the operational realities were familiar. We expanded the team for the push and shipped on August 18, 2025, the date Inside Real Estate had committed to. This is how.

Key Takeaways

• A public ship date is an architecture forcing function. It shapes what you build as much as when you ship it.
• With capable models in hand, the production platform around them is the real work, and where most AI projects stall.
• We shipped HomeSearch AI across BoldTrail and CORE Home in five months, to 400,000 agents, on the committed date.
• One search service carried both classic and AI queries from launch, sustained at around a thousand requests per second.

Because the model is the easy part. Gartner expects at least 30% of generative AI projects to be abandoned after proof of concept by the end of 2025, citing poor data quality, weak risk controls, and unclear value (Gartner, 2024). A demo proves a model can answer. Production has to answer for every user, every query, under load, every time.

We started past the demo. The models came with the acquisition, and they worked. What did not exist was everything that turns a model into a product: the service that serves it, the data it reads, the latency budget, the observability, and the surrounding features that make it worth using. That is the work a deadline actually buys you time for, and the work that decides whether an AI launch is real.

Yes, and the deadline is part of why. Both products needed AI search, and both still needed classic filter search for the agents and consumers already using it. A second AI system bolted alongside the old one would have meant two query paths, two ranking layers, two failure modes, and two chances to drift. We built one search service that owned both, served from a single contract.

We wrote it from scratch in Java and Spring, so one contract could carry classic filters and AI-driven queries with mature observability, tracing, and the predictable performance a core product service needs under launch load. One service is also the version you can actually finish in five months, because one system is far less to hold in your head than two kept in sync.

It held. One service behind two products, sustained at around a thousand requests per second for 400,000 agents from launch day.

Making it the default input. Buyers do not search the way an MLS schema thinks about homes. They say “3 bedroom home with a pool under $600k” or “modern home with lots of light,” typed or spoken. The job was to make that the normal way to search.

Underneath, the query pipeline extracts intent, normalizes it against the listing data, and falls through cleanly to classic filters when an intent slot does not resolve, without the user noticing they crossed a boundary. Voice runs through the same pipeline, so the behavior is identical whichever way a buyer asks. The fall-through is what keeps it reliable: a query the model cannot fully parse still returns real results.

You put them on the same service as live search. BoldTrail sends roughly 160 million search alerts a month, and each one has to decide what to send, when, and to whom. We rebuilt that pipeline on top of the new search service so alerts speak the same intent language as live search, and ranking and timing decisions live in the search service, where before they were scattered across email templates and CRM jobs.

Dormant-lead reactivation runs on the same primitives. When a lead has gone quiet, the system uses their historical intent to decide whether anything new on the market is worth a re-engagement, and surfaces it to the agent when it is most likely to land. The whole stack sits behind an A/B framework, so the Inside Real Estate product team can keep tuning the model layer, the ranking weights, and the alert copy after launch without redeploys.

Let the date drive the architecture. A public ship date pushes you toward one durable system and away from the clever, fragile one, because the fragile one is the one that misses the date. The constraint is not the enemy of good engineering here. It is what rules out the options that would not have held anyway.

The other lesson is to build the tuning in. We shipped the A/B framework as part of the launch, so the date was a start rather than a freeze. An AI feature is never done at launch; the model layer and the ranking keep moving. Shipping the means to tune them is part of shipping the feature.

The models will keep getting better, and more teams will start from a capable one the way we did. The advantage moves to whoever can build the production platform around it, on a date that customers have already heard. That is the work we do when we build AI features into a product; the full HomeSearch AI case study has the architecture and the numbers. The model gets you a demo. The platform gets you a launch.