An AI-assisted housing search proof of concept for Manchester, focused on preference capture, soft ranking, tradeoff discovery, and explainable property recommendations.
This project explores what a smarter property-search experience could look like if it went beyond rigid filters such as “max price”, “minimum bedrooms”, and “property type”. Instead, it captures a user’s housing intent, converts it into a structured preference profile, ranks candidate properties using weighted scoring, and explains why each result may be a good fit.
Status: Portfolio proof of concept / active rebuild foundation Location focus: Manchester, UK Core themes: data engineering, ranking systems, recommender systems, geospatial enrichment, explainable AI, LLM-assisted UX
Most property portals rely on hard filters. That works when a user knows exactly what they want, but housing decisions are usually full of tradeoffs:
- more space vs better schools
- lower price vs better area fit
- shorter commute vs quieter location
- stronger transport links vs larger homes
- strict budget vs stretch-budget opportunities
This project tests a more intelligent search flow where the system behaves like a preference interpreter and option explorer, not just a filter form.
Instead of hiding every property that misses one constraint, the system can surface strong alternatives and explain the compromise.
The current proof of concept supports a local guided workflow that:
- asks the user structured housing-preference questions
- converts answers into a validated preference profile
- applies hard constraints where appropriate
- scores remaining properties using soft weighted preferences
- returns the top ranked matches
- generates alternative “what if?” tradeoff scenarios
- explains why each property ranked well
- explains what the user gives up compared with other options
Example tradeoff scenarios include:
- What if your budget was higher?
- What if transport mattered less?
- What if school access mattered more?
- What if low crime mattered more?
- What if you wanted more internal space?
This project demonstrates end-to-end product and engineering thinking across:
| Area | What this repo demonstrates |
|---|---|
| Data engineering | Multi-stage feature pipeline using public housing, postcode, amenity, school, crime, deprivation, and price-context data |
| Geospatial analysis | Postcode centroids, distance features, amenity access, commute anchors, and local-area context |
| Recommender systems | Weighted ranking, soft preferences, hard constraints, missingness-aware scoring, and scenario reranking |
| Explainability | Human-readable explanations showing why a result ranked well and what tradeoff it represents |
| Applied AI / LLMs | Structured preference capture with optional local LLM rewriting for buyer-friendly explanations |
| Product thinking | A real user problem framed around preference discovery rather than simple portal filtering |
| Testing discipline | Regression checks for important behaviour such as negation handling, budget semantics, commute effects, and tradeoff diversity |
A user should be able to describe what they want in natural language or through guided questions:
“I’m looking for a family home near good schools, ideally under £300k, but I’d stretch if the area is much better. I need access to the city centre and I’d prefer to avoid end-terrace houses.”
The system turns this into a structured profile such as:
- household mode
- property type
- preferred or excluded built form
- minimum bedrooms / rooms
- target budget
- stretch budget
- commute target
- school priority
- transport priority
- crime priority
- additional free-text notes
- pairwise tradeoff preferences
The ranking system then returns both the best overall matches and alternative options that reflect different tradeoff strategies.
Rightmove-AI/
├── demo/
│ ├── incremental_chat_demo.py
│ ├── incremental_extractor.py
│ ├── preference_schema.py
│ ├── preference_validator.py
│ ├── ranker.py
│ ├── run_regression_checks.py
│ ├── quick_profile_runner.py
│ ├── quick_compare_commutes.py
│ └── sample_preferences_current.json
│
├── src/
│ ├── 01_download_codepoint_open.py
│ ├── 02_extract_manchester_postcodes.py
│ ├── 03_download_osm_pois_manchester.py
│ ├── ...
│ ├── 22_join_school_quality_into_property_v5.py
│ ├── 23c_apply_quality_rules_v1.py
│ └── 23d_export_paraquet.py
│
├── docs/
│ ├── pipeline_reference.md
│ ├── preference_schema.md
│ ├── qc_v1_summary.md
│ ├── final_dataset_schema_property_features_v5_clean.md
│ └── representativeness_report.md
│
└── README.md
The guided demo avoids unreliable one-shot extraction by asking focused questions and updating the user profile incrementally.
It captures:
- buyer / renter persona
- property type
- built-form preference
- exclusions such as “anything but end-terrace”
- bedroom requirements
- budget and stretch budget
- transport needs
- low-crime priority
- commute target
- extra notes
- pairwise tradeoffs
Preference validation happens after updates so invalid or vague inputs do not silently corrupt the ranking profile.
The preference profile separates:
- hard constraints — must-have requirements
- soft preferences — weighted scoring dimensions
- tradeoffs — explicit preference shifts
- budget semantics — target budget, stretch budget, and strictness
- commute target — used to influence ranking rather than simply stored as text
This separation makes the system easier to debug, test, and extend.
The ranking engine scores candidate homes across several dimensions:
- space
- school access
- park access
- transport
- price fit
- local crime context
- energy efficiency
The ranker combines hard constraints with soft weighted scoring. This allows the system to avoid the common property-search problem where good options disappear simply because one field is slightly outside a strict filter.
The demo returns a primary shortlist and a set of alternative scenario cards.
This is designed to answer questions such as:
- “What improves if I stretch my budget?”
- “What do I gain if I care less about transport?”
- “What changes if schools become the main priority?”
- “Which options offer more space, and what do they give up?”
The goal is not only to rank properties, but to help users understand the decision space.
Each result includes explanation fields such as:
- why the property ranked well
- which score dimensions helped it
- how it differs from the best match
- what tradeoff it represents
- who the option may suit
The project also includes an optional local LLM rewriting step that can turn deterministic explanation facts into a more natural buyer-facing summary.
The key design principle is:
Facts are generated deterministically first. The LLM can improve tone, but should not invent reasons.
The Version 1 dataset is a Manchester-area enriched housing dataset built around EPC property records and postcode-level context.
- Ordnance Survey CodePoint Open postcode centroids
- OpenStreetMap / OSMnx points of interest
- EPC Domestic records
- HM Land Registry Price Paid Data
- Police.uk crime data
- ONS Postcode Directory
- IMD 2019 deprivation indicators
- school location and Ofsted-related school quality data
The final ranking dataset includes features such as:
- property identity and location
- EPC property attributes
- floor area
- habitable rooms
- energy rating
- distance to parks, bus stops, tram stops, rail stations, schools, GPs, hospitals, pharmacies, and supermarkets
- nearby amenity counts
- postcode-level price context
- local crime aggregates
- deprivation indicators
- school-quality indicators
- quality flags and missingness indicators
The next version of the project moves toward a listing-led architecture using static Rightmove listing snapshots as a seed source.
The listing layer includes fields such as:
- URL
- property ID
- location
- price per calendar month
- price per week
- property type
- bedrooms
- bathrooms
- size
- description
- key features
- parking
- garden
- accessibility
- council tax
- rental metadata where available
Important note: this repo is a proof of concept. Any use of portal data should respect the relevant website terms, robots policies, copyright, and applicable law. The project is not affiliated with Rightmove.
git clone https://github.com/maxautomateseverything/Rightmove-AI.git
cd Rightmove-AIpython -m venv .venvActivate it:
# Windows
.venv\Scripts\activate
# macOS / Linux
source .venv/bin/activateThe repo currently focuses on scripts rather than packaged installation. For the demo layer, install the core Python dependencies used by the ranker and guided workflow:
pip install pandas numpy pyarrow requestsSome data-pipeline scripts may require additional geospatial and API-related packages depending on which stage you run.
Recommended next repo improvement: add a pinned requirements.txt or pyproject.toml.
The active guided demo expects the enriched Parquet dataset at:
data/features/property_features_v5_qc_v1.parquet
Run the guided workflow:
python demo/incremental_chat_demo.pyRun a saved preference profile without answering the full questionnaire:
python demo/quick_profile_runner.py --profile demo/sample_preferences_current.json --top-n 5Compare how commute targets affect results:
python demo/quick_compare_commutes.pyRun regression checks:
python demo/run_regression_checks.pyWho is this search for?
> family
Which property type do you want?
> house
Any built-form preference?
> anything but end-terrace
Minimum bedrooms needed?
> 3
Need good public transport nearby?
> yes
Is low crime a high priority?
> yes
Target budget?
> 300000
Stretch budget?
> 340000
Commute target?
> city centre
The system then builds a structured preference profile and returns:
- top 5 best overall matches
- candidate counts after constraints
- score totals
- explanation summaries
- tradeoff alternatives
The project includes checks for important behaviours that are easy to break during iteration:
- negation handling, such as “anything but end-terrace”
- bedroom validation
- soft budget behaviour
- commute target influence
- score-driver explanations
- distinct tradeoff alternatives
These checks help keep the demo stable while the ranking and preference logic evolve.
A user’s budget is treated as:
- target budget
- stretch budget
- optional strict mode
This allows the system to show when a slightly higher price unlocks better options.
Instead of relying on one large prompt to extract everything, the system uses a guided flow with validation after each step.
This is more reliable, easier to debug, and better suited to tradeoff-heavy decisions.
A useful housing recommender should not only say:
“This property is close to a school.”
It should explain:
“This ranked higher because it balances school access and price better than the alternatives, but gives up some internal space.”
The project treats missing or low-confidence data as part of the ranking problem rather than pretending every field is equally reliable.
This is a proof of concept, not a production property-search platform.
Known limitations include:
- Version 1 is EPC-led rather than fully listing-led
- some features are proxies rather than exact listing facts
- some listing fields are incomplete or inconsistent
- deduplication across multiple listing sources is not yet fully implemented
- location confidence and listing-to-enrichment joins need a cleaner Version 2 design
- setup should be improved with pinned dependencies and clearer data-download instructions
- the current README and docs can be further split into user docs, developer docs, and case-study docs
These limitations are useful because they define the next engineering steps.
Version 2 is planned as a clean rebuild around a listing-led architecture.
The main direction is to separate:
- raw listing fields
- normalized listing fields
- derived ranking features
- enrichment joins
- provenance
- confidence scores
- quality flags
The goal is to preserve the strongest parts of Version 1 — preference capture, ranking, tradeoff scenarios, and explanations — while using listings as the primary search unit.
Planned next steps:
- define a canonical listing schema
- create a clean listing identity / deduplication layer
- add confidence scoring for listing fields
- design listing-to-enrichment join rules
- rebuild the ranker around listing-first records
- add a simple UI or API wrapper
- add screenshots or terminal demo recordings
- add pinned dependency management
- add automated tests for the ranking engine
- add sample anonymised/demo data for easier portfolio review
This project surfaced several important lessons:
- ranking systems need explicit tradeoff design
- soft constraints are often more useful than strict filters
- user preference extraction is more reliable when guided and validated
- explanations should be contrastive, not just descriptive
- LLMs are most useful when grounded by deterministic facts
- data quality and missingness are product issues, not just engineering issues
- a portfolio project is stronger when it shows decisions, limitations, and iteration history
- Python
- pandas / NumPy
- geospatial feature engineering
- data cleaning and profiling
- public-data integration
- recommender-system design
- ranking and scoring logic
- preference modelling
- explainable AI
- local LLM integration
- regression testing
- product thinking
- technical documentation
This is an independent proof of concept for portfolio and learning purposes. It is not affiliated with, endorsed by, or connected to Rightmove. Any portal data should be handled responsibly and in line with relevant terms, copyright, and applicable law.