Hestia: find your home

Front image
Individual Property Page
Filtering by commutability
Showcasing map and filters
Showcasing map
Showcasing map layers (train noise)
Showcasing map layers (road noise)
Planning whiteboard 1
Planning whiteboard 2

Problem that we are solving

Choosing the right home is one of the biggest decisions you'll make, yet Rightmove does the bare minimum to help. While it can show distances to chosen locations, there is no way to filter homes based on commute time. Critical information like local crime rates, noise levels, air quality and train availability exists in public datasets but is never surfaced to buyers, with listings relying entirely on whatever the estate agent chooses to include. And when a property you love falls through, there is no way to find similar listings based on what actually drew you to it in the first place.

Overview of Project

Our project aims to address Rightmove’s limitations and provide additional functionality to make finding your perfect home easier. We enable filtering by commute time to any chosen location, and provide a shortcut to filter for distance to the nearest train station, allowing you to choose a home convenient for commuting, shopping, going out, or any other needs.

distance to X feature

We utilise a similar layout to Rightmove for simplicity and ease of use, but incorporate optional visualisations of noise levels, flood risk, crime rates, air quality, and nearby school locations to enhance your understanding of a given area, all of which can be filtered on too!

filter view

We also allow filtering out of % ownership schemes, an increasingly prevalent but undesirable phenomena.

When you’ve selected a property, view the rating of the estate agent to avoid unsavoury dealers, see nearby schools, amenities, and view train-lines running through the area, and view ML predicted forecasts for property prices in the area based on hidden factors like flood risk and crime rate.

individual property xray

price forecasting

If you like a property but aren’t quite sold, or just miss what looks like a dream home, find similar properties based on single images or the property as a whole using our smart similarity-search feature to find a better alternative!

vector search visual

vector search visual 2

Not sure what filters to use? Our fuzzy search feature will match a vibe to the best filters to get you on your way to finding your dream home.

Architecture & Tech Stack

Hestia uses a modern tech stack, which enables a horizontally scalable data processing pipeline. The backend uses Ruby on Rails, Redis, Sidekiq and Postgres, with Python also used for training and calling in house ML models. The frontend uses React, Typescript and Vite. The backend and frontend communicate through a REST API.

tech stach visual

Ruby on rails is a full stack model, view, controller framework which enables rapid prototyping because of its well designed abstraction layers, which is why we chose it for this hackathon.

Sidekiq enables horizontally scalable compute, which allowed us to ingest almost 10,000 Rightmove listings, generate embeddings for them, and enrich them with additional data within the timeline of the Hackathon. Redis is the caching layer Sidekiq uses.

We chose Postgres because it works well natively with Rails, allows us to store json objects in the database as unstructured fields, and works with the pgvector gem which is essential for storing embeddings for our similar properties feature.

React, Typescript and Vite allowed us to develop a complex frontend in a short amount of time. It had out of the box solutions for creating maps which was very important for our use case.

This project involved bringing together lots of 3rd party data sets through either APIs or CSV files, we used the Gateway pattern in Rails to enable this, which ensures clear separation of concerns.

Our base data model is closely based on the data we could reliably scrape from Rightmove listings, and we normalised the data after we had a better idea of it. For example, moving real estate agents into their own models to prevent duplication and unnecessary excess API calls to enrich them with review data.

Teamwork

To distribute the workload, we brainstormed our ideas on the room whiteboards, developing an escalating ladder of complexity for each feature area. We then assigned feature areas to the team evenly and based on interest. This escalating ladder allowed us to iteratively develop from MVP to fully viable product in a continous and fluid manner. Continually, we communicated openly, allowing for fluid group problem solving and quick mixing of ideas from each of our perspectives. Problems were struck down via group effort upon immediate discovery and verbal reporting. This produced and effective, aligned and enjoyable development process for the whole team.

Data Sources

Hestia brings together sevral main data sources: Police API for street-level crimes, Nominatim for Geocoding Info, HM land registry for Historial house sale prices, Google Reviews for Estate Agent Rating, ⁠ONS for Schools data and Flood risk data, Rightmove listings, DEFRA/DAQI for air quality index

We found it very surprising that Rightmove doesn’t take into account anything beyond very basic data enrichment, and doesn’t allow filtering on any of those fields! Hestia allows users to avoid common pitfalls which are hard to know about, and hard to filter for, when build their home. Not only did we normalise this data and bring it into our data model to enable filtering, we built on top of it. For example, we trained an in house ML model on almost all of these data points to predict future house prices.

Challenges We Solved

Rate Limiting on Crime API: We quickly found ourselves being rate limited by our crime statistics API. To overcome this, we had to employ Sidekiq throttling with exponential backoff to ensure we could take in as much data as possible without being blocked. Unfortunately, this still left some properties without data so we employed region buckets, i.e. taking the crime statistics of the closest property with them to enable close-to-real visualisation.

Bulk Collection of Rightmove Listings: Naturally, collecting thousands of Rightmove listings is relatively gruelling if requesting one property page at a time. To get around this, we used a horizontally scalable queue to go through all listings, accelerating retrieval via concurrent requests.

Long Naive Vector Search Time: When finding similar properties, a naive vector search must perform embedding count * dimensionality queries every search. To accelerate this, we employed k-ANN search in the form of the state of the art HNSW algorithm, massively accelerating search times at the cost of a small amount of precision.

Travel Time Calculation: While we initially wanted to calculate pairwise distances on a grid across all of London (which would have enabled quick distance calculations at runtime), we quickly realised this was impractical due to the billions of possible calculations, instead choosing to use call an API to calculate Isochronic distances at runtime.

Outlier Removal: When creating the Choropeth map, we had one property that had a cost of £70,000 per square foot, massively distorting the scale.

ML/AI usage

Hestia runs two PyTorch neural networks: one trained on Land Registry data to forecast prices 1-3 years ahead, and one trained on live listings with k-fold cross validation to estimate current fair value and flag over or underpriced properties. For explainability we use Integrated Gradients over Shapley values because it runs in a single pass with fixed interpolation steps, making it fast enough for real-time inference while still satisfying completeness, meaning attributions faithfully sum to the prediction difference.

price forecasting

For similar property search, we embed images with DINOv2 and descriptions with MiniLM, store them in pgvector with HNSW indexing, and re-rank candidates using a weighted hybrid of image and text cosine distances. Natural language search is powered by GPT-4o-mini, which translates plain English queries into structured filters across all enriched data fields.

vector implementation slide

vector search visual

vector search visual 2

Design (UI)

While rightmove is bright and clean, we wanted to opt for a more homely, warmer design for our application, hence the name Hestia, chosen for the ancient Greek goddess of the hearth. Although we opted for broadly pastel tones, brown and orange accents were chosen to maintain that general feeling of warmth throughout.

We tried to keep the interface relatively clear to avoid confusing the user, as is easy when adding so many choices. A part of that idea led to the creation of our fuzzy search, enabling uncertain users to skip manually adjusting the filters, instead allowing them to just type their general feeling and have it be matched to filters for them. Controls over factors like air pollution and noise were kept to their original scales to allow precise control over these factors for users who wished to utilise them.

When viewing an individual property, map views of the area around properties always visualised schools as green dots for consistency, keeping them distinct from other categories of place that kept to other colours. Additionally, darkness levels and boundary lines were used to clearly show walkability boundaries of 5, 10, and 15 minutes around the area. Transport links were displayed clearly with times in minutes and place names, as were air pollution and noise levels.

individual property xray

flight noise

rail noise

road noise

Finding similar properties could be done from the property menu at the touch of a button, with similar properties popping up below, viewable from a click on their pages, and closable with a simple x should a misclick have caused its appearance.

Limitations And Future Work

For image and text embeddings, we were limited to smaller embedding models due to inference time constraints. Given more time, we could have used larger, higher-quality models that would likely produce more accurate embeddings. Similarly, our ML models were constrained by the quality and quantity of data we could collect within 24 hours, and with further development these models could be significantly improved.

Due to the time limit, we scoped the project to Rightmove sales listings in London only. With more time we could have processed listings across a wider range of areas within the UK, and incorporated additional data sources for each property.

Looking ahead, we would like to extend the project to cover Rightmove rental listings with a similar enrichment experience. We chose not to include rentals in this iteration as they have different properties to sales listings and we did not want to dilute the scope. We would also like to implement features such as image-based search, where a user could upload a photo of the aesthetic they want and find visually similar properties.

What We Learned

We learned that building a strong property platform is less about showing listings and more about handling messy data, scaling collection, and making smart trade-offs between accuracy, speed, and usability.

It was also some of the team members first time using ruby on rails, so it took us a while to get warmed into it. We also learned alot about geohashing, as it was used a lot in the project.