Executive Summary
Days on Market is a production-oriented machine learning system designed to estimate how long a real estate property may remain on the market before being sold.
Rather than presenting a single opaque prediction, the application compares three regression models, exposes confidence ranges and highlights the influence of pricing through a carefully engineered market-position feature.
The project explores how predictive machine learning systems should be designed when interpretability, uncertainty and feature engineering matter more than model complexity.
Engineering Challenges Solved
- Predictive Machine Learning
- Feature Engineering
- Regression Model Comparison
- Uncertainty Estimation
- Reproducible Training Pipelines
- Structured Data Preprocessing
- Model Serving
- Production ML API
Problem
Estimating how long a property will remain on the market is difficult because selling time depends on many interacting factors, including price, location, surface area, energy performance and property condition.
Agents often rely on experience and local intuition, but these estimates can be inconsistent and difficult to justify.
A useful predictive system must therefore do more than output a number. It must identify the variables that truly drive the prediction, communicate uncertainty and remain understandable enough to support human decision-making.
Why This Problem Matters
Predictive models influence pricing, marketing strategy and seller expectations.
An inaccurate estimate can lead to unrealistic promises, inappropriate listing prices or poor commercial decisions.
The engineering challenge is therefore not simply to optimize a regression metric, but to build a reproducible and interpretable decision-support system that communicates both predictions and their limitations.
System Architecture
Technology Stack
- Python
- FastAPI
- scikit-learn
- XGBoost
- Pandas
- Pydantic
- React
- TypeScript
- Docker
Key Engineering Decisions
Feature Engineering Before Model Complexity
The most influential feature in the project is not a raw property attribute, but a derived pricing ratio comparing the listing price with the estimated local market value:
listing_price / (surface × market_price_per_m²)This feature captures whether a property is positioned above or below its local market.
Once introduced, even linear regression reached performance close to more complex tree-based models.
This demonstrated that representing the problem correctly can matter more than selecting a more sophisticated algorithm.
Compare Multiple Models Instead of Selecting One Too Early
The application trains and exposes Linear Regression, Random Forest and XGBoost using the same dataset and preprocessing assumptions.
Rather than treating the most complex model as the default winner, the system compares their MAE, RMSE and R² values.
This makes model selection evidence-based and reveals whether additional complexity produces a meaningful operational benefit.
Expose Uncertainty Instead of a False Exact Answer
A prediction such as “47 days” may appear precise while hiding substantial uncertainty.
The application therefore returns a lower and upper estimate alongside the central prediction.
This turns the output into a decision-support signal rather than an artificial guarantee and provides users with a more realistic representation of model confidence.
Keep Training and Inference Separate
Model training is executed through a dedicated pipeline that performs preprocessing, fitting, evaluation and artifact persistence.
The production API loads previously trained model artifacts and performs inference only.
This separation avoids retraining during application startup, improves reproducibility and keeps production behavior predictable.
Machine Learning Pipeline
The project separates the machine learning lifecycle into distinct stages:
All models receive a consistent representation of the data, making their performance directly comparable.
The application then serves either one selected model or all three models in parallel, allowing users to compare their predictions and associated metrics.
Trade-offs
The synthetic dataset provides complete control over data generation and makes experimentation reproducible.
However, synthetic relationships are necessarily simpler than real property markets and may not reproduce geographic variation, economic cycles or behavioral effects.
Comparing three models also increases training and maintenance complexity, but provides a clearer understanding of whether model sophistication creates measurable value.
Finally, confidence ranges improve communication, but they should not be interpreted as formally calibrated guarantees without stronger statistical validation.
Production Considerations
The system was designed with a clear separation between experimentation and serving.
Key architectural concerns include:
- reproducible preprocessing;
- persisted model artifacts;
- shared feature definitions between training and inference;
- typed API contracts;
- application-level model comparison;
- health checks exposing model availability;
- automated linting and type checking;
- containerized deployment;
- isolated training commands;
- prevention of preprocessing drift.
These decisions reduce the risk of producing different feature representations during training and production inference.
Results
The three models achieved similar performance on the synthetic dataset, with an MAE of approximately eight days and an R² close to 0.89.
The most important result was not that XGBoost outperformed the alternatives, but that Linear Regression became similarly effective after introducing the pricing-ratio feature.
This showed that the structure and quality of the input representation had a greater impact than model complexity in this problem.
Metrics Tracked
- Mean Absolute Error
- Root Mean Squared Error
- R² Score
- Prediction Interval Width
- Training Duration
- Inference Latency
- Model Agreement
- Error Distribution
- Feature Importance
- API Response Time
What I Learned
The choice of model is often less important than the way the problem is represented.
Before introducing the derived pricing-ratio feature, the models had to infer the relationship between price, surface and local market conditions independently. Once that relationship was explicitly encoded, even a simple linear model performed competitively with XGBoost.
This project reinforced the idea that feature engineering, data quality and evaluation design frequently create more value than increasing model complexity.
It also highlighted the importance of communicating uncertainty: a useful machine learning system should support human judgment rather than present probabilistic estimates as certain outcomes.
Future Directions
- Training with real DVF and listing data
- Temporal validation across market periods
- Geographic cross-validation
- Hyperparameter optimization
- Explainability with SHAP
- Calibrated prediction intervals
- Drift detection
- Automated retraining
- Feature store integration
- Market-segment-specific models