AI Property Valuation Model (AVM)

Project overview

We built an automated valuation model (AVM) for a property listings and brokerage business. Agents and analysts send a property's address and attributes to an API and get back an estimated price, a likely range, the comparable sales that drove it and a confidence flag that decides whether a person should review the figure.

The work covered data audit, feature engineering, model training, a valuation service and an analyst dashboard, delivered through our machine learning development team. It is part of a wider body of real estate software we have built for brokers, landlords and property managers.

The client and the challenge

Valuations were produced by hand. Agents pulled comparable sales from spreadsheets, adjusted for size and condition by instinct, and two people looking at the same flat could arrive at noticeably different prices. Pricing appraisal requests took days to turn around, and nobody could explain afterwards why a given figure was chosen.

The client wanted a consistent first estimate for every property, a clear explanation agents could share with sellers, and an honest signal when the data was too thin to trust the model. Historical sales records were messy: duplicate listings, missing floor areas, inconsistent property types and addresses that did not geocode cleanly. Some neighbourhoods had plenty of recent sales while others had only a handful, so a single global accuracy figure would have hidden exactly the areas where the model was weakest.

Solution architecture & delivery

We started with the data. Sales and listing records were deduplicated, addresses geocoded and property types mapped to one taxonomy. Using GeoPandas we joined each property to its neighbourhood boundary and derived location features such as distance to transit, schools and commercial centres, plus the recent price level of nearby sales within walking distance.

The model itself is a gradient-boosted LightGBM regressor trained on log price, with separate quantile models producing a lower and upper bound. We validated on a time-based split, training on older sales and testing on the most recent ones, so the evaluation reflected how the model would actually be used rather than leaking future prices into training.

Each estimate returns the price, the range, the strongest feature contributions and the closest comparable sales. When the range is wide, the property is unusual or there are few nearby comparables, the valuation is marked low confidence and routed to an analyst queue in the dashboard, where staff can accept, adjust or override it with a reason that is stored for retraining.

A scheduled pipeline retrains the model on new sales, compares it against the live version on a holdout set and only promotes it after an analyst signs off. Drift reports show when prices in a neighbourhood move away from the model's recent predictions. Release and testing steps follow our CI/CD pipeline.

Key features we built

• Valuation API returning price estimate, range and confidence flag
• Location features derived from neighbourhood boundaries and nearby amenities
• Comparable sales shown alongside every estimate
• Per-estimate explanation of the features that moved the price
• Analyst review queue for low-confidence valuations with override reasons
• Time-based evaluation reports by neighbourhood and property type
• Scheduled retraining with sign-off before a new model goes live
• Drift monitoring that highlights areas where prices are shifting

How we delivered it

1. Data audit. Profiling of historical sales and listings, agreeing cleaning rules with the analyst team and identifying which attributes were reliable enough to use.
2. Modelling. Feature engineering and baseline models, then LightGBM price and quantile models compared against the client's manual valuations on recent sales.
3. Build. Two-week sprints delivering the valuation API, analyst dashboard and retraining pipeline in parallel.
4. Shadow run. The model priced incoming requests alongside agents without being shown to sellers, so we could tune confidence thresholds before launch.
5. Launch and support. Gradual roll-out to agent teams, followed by monitoring, retraining and feature additions under a support agreement, similar to our other property platform work.

Technology choices

• Python — one language for data cleaning, model training, evaluation and the valuation service, which kept the pipeline simple to maintain.
• LightGBM — fast, accurate gradient boosting on tabular property data, with quantile objectives for price ranges and feature contributions for explanations.
• GeoPandas — spatial joins to neighbourhood boundaries and distance calculations to amenities and comparable sales.

Outcomes

• Agents start from a consistent model estimate instead of assembling comparables by hand
• Every valuation comes with comparables and reasons that can be shared with sellers
• Unusual or data-poor properties are flagged for an analyst rather than priced blindly
• Analyst overrides feed back into retraining, so the model learns from local expertise
• Management can see where the market is moving through neighbourhood drift reports
• Appraisal requests are answered the same day instead of waiting in a manual queue

FAQ