A walk-through of the entire pipeline I actually ran — from a messy first look at 10,000 rows of housing data to a live Streamlit app — including the code, the real outputs, and the mistake I nearly shipped.
I wanted to answer a simple question for myself: if I hand a machine learning model nothing but a property’s physical stats — its size, its rooms, its amenities — how close can it get to the actual price, and can I turn that into something a total stranger could use in their browser in under ten seconds? This post is the honest, step-by-step record of how I built that system: a Paris housing dataset, three competing regression models, a correlation heatmap that gave away the dataset’s biggest secret, and a Streamlit app that’s live right now.
Property valuation is one of those problems that sounds simple until you actually sit with it. Price a house too high and it sits on the market for months, quietly bleeding carrying costs. Price it too low and the seller just handed away equity. Every real estate agent, lender and buyer is implicitly running a valuation model in their head — I wanted to build an explicit, testable, reproducible one instead.
I also picked this project because it’s genuinely end-to-end. It isn’t a notebook that stops at a nice R² score. It forced me through the full lifecycle I care about as an ML engineer: ingesting raw data, interrogating it honestly, comparing multiple algorithms instead of assuming the fanciest one wins, serializing a model correctly, and wiring it into a web app that a non-technical person can actually use. That last part matters to me — a model sitting in a .ipynb file has never helped anyone make a decision.
ParisHousing.csv. It’s a synthetic dataset modeled on an urban housing market, and it comes with 10,000 records and 17 columns, with price as the target I was trying to predict. | Category | Columns |
|---|---|
|
Demographics |
Age, Gender, Marital Status, Education, Profession |
|
Household |
No. of Dependents, Partner Working |
|
Finances |
Salary, Partner Salary, Total Salary, Personal Loan, House Loan |
|
Purchase |
Make (car type), Price |
joblib for serialization and, eventually, streamlit. # For data manipulation and analysis
import pandas as pd
import numpy as np
# For visualization
import matplotlib.pyplot as plt
import seaborn as sns
# Preprocessing, splitting, evaluation
from sklearn.model_selection import KFold, cross_val_score, train_test_split
from sklearn.impute import SimpleImputer
from sklearn.preprocessing import OneHotEncoder, StandardScaler
from sklearn.metrics import mean_absolute_error, mean_squared_error, r2_score, make_scorer
# Models
from sklearn.linear_model import LinearRegression, Ridge
from sklearn.ensemble import RandomForestRegressor
from sklearn.tree import DecisionTreeRegressor
from xgboost import XGBRegressor
import warnings
warnings.filterwarnings('ignore')I also set a couple of pandas display options early on — nothing glamorous, just quality-of-life so I wasn’t staring at scientific notation for a 7-figure price column:
# To suppress scientific notation
pd.set_option("display.float_format", lambda x: "%.3f" % x)
pd.set_option("display.max_columns", None)
pd.set_option("display.max_rows", 200)I ran this project in Google Colab, so the data came in straight from Drive:
data = pd.read_csv('/content/drive/My Drive/ParisHousing.csv')
data.head()First instinct: check the shape and structure before I trust anything I’m looking at.
data.shape
# (10000, 17)
data.info()FIELD NOTE
Every single column is fully populated — 10,000 non-null entries across the board, and everything is numeric. No text fields to encode, no dates to parse. That’s unusual, and I made a mental note of it before moving on, because clean data like this almost never happens on organic, real-world housing records.
data.describe().T gave me the statistical shape of every column at once — and one number jumped out immediately: the average squareMeters was 49,870 m², with a standard deviation of nearly 28,800. That’s not a typical Paris apartment — that’s a small stadium. It was my first hint that I was working with a procedurally generated dataset, not a scrape of real listings. I don’t trust a “clean-looking” dataset until I’ve actually checked it. So, duplicates and missing values, both ways:
# Duplicate rows
data.duplicated().sum()
# Missing values, sorted
missing_value_count = data.isnull().sum()
missing_value_count.sort_values(ascending=False)
total_missing = missing_value_count.sum()
print(f"Total number of missing values: {total_missing}")SimpleImputer or start deciding between median and KNN imputation — here, there was nothing to fix. I kept the import in my toolkit out of habit, but it never got used in this particular pipeline. This is the part of any project I refuse to rush. Before I let a model near this data, I wanted to actually understand the shape of every feature and how it relates to price.
I plotted histograms with KDE curves for the core numeric features:
numeric_cols = data.select_dtypes(include=np.number).columns.tolist()
colors = sns.color_palette("husl", len(numeric_cols))
n_cols = 3
n_rows = (len(numeric_cols) + n_cols - 1) // n_cols
plt.figure(figsize=(18, 5 * n_rows))
for i, col in enumerate(numeric_cols):
plt.subplot(n_rows, n_cols, i + 1)
sns.histplot(data[col], kde=True, color=colors[i], bins=15)
plt.title(f"Distribution of {col}")
plt.tight_layout()
plt.show()
Every one of these is close to a flat, uniform distribution across its full range. Real housing markets don’t look like this — real square-footage and price distributions skew right, with a long tail of expensive luxury properties and a dense cluster of typical homes. Here, a 5,000 m² house is just as likely to appear as a 50,000 m² one. That’s engineered data talking.
The binary amenity features told the same story — hasYard, hasPool, isNewBuilt, hasStromProtector, and hasStorageRoom were all sitting close to a 50/50 split. Great for balanced model training, but not how amenities are distributed in an actual city.
This is where the correlation heatmap came in, and it’s the single most important chart in this entire project:
plt.figure(figsize=(12, 8))
sns.heatmap(data.corr(numeric_only=True), annot=True, fmt=".2f", cmap="coolwarm")
plt.title("Feature Correlation Heatmap")
plt.tight_layout()
plt.show()
WHAT THE HEATMAP TOLD ME
squareMeters correlates with price at 1.00. Not 0.9-something — 1.00. Every other feature, including things I’d have guessed mattered like cityPartRange or hasPool, sits at roughly ±0.02, statistically indistinguishable from noise.
I double-checked this with a straight scatter plot, and it removed any doubt:
plt.figure(figsize=(8, 5))
sns.scatterplot(data=data, x='squareMeters', y='price', alpha=0.6, color='green')
plt.title('Price vs Square Meters')
plt.show()
I’ll be honest — the first time I saw that scatter plot, I assumed I’d made an error somewhere. Ten thousand points, and every one of them falls exactly on a single line. There’s no scatter, no noise, no outlier estate that breaks the pattern. That’s not what correlation looks like in real markets; that’s what a mathematical formula looks like.
I also checked whether the property’s location or age carried any signal. I grouped average price by construction year:
yearly_price_trend = data.groupby('made')['price'].mean().reset_index()
yearly_price_trend = yearly_price_trend.sort_values(by='made')
plt.figure(figsize=(12, 6))
plt.plot(yearly_price_trend['made'], yearly_price_trend['price'], marker='o', color='teal')
plt.title('Average Property Price by Year Built')
plt.show()
cityPartRange, expecting the more “exclusive” zones to command a premium: 
WHY THIS MATTERS
In a real housing market, location and vintage are two of the biggest price levers there are. Here, neither made a measurable difference. That told me the data generator behind this Kaggle dataset almost certainly computed price as a near-direct function of squareMeters, with everything else added as light, mostly cosmetic noise. It reframed the entire project for me: I wasn’t hunting for a subtle signal buried in the data — I was trying to recover a formula.
But when I built the input array inside the Streamlit app, I laid the widgets out in whatever order made sense for the UI — and the resulting array ended up in a different order:
As a small side experiment, I engineered one new feature — a count of how many properties were built in the same year as each row, to see if construction-year density carried any predictive value:
properties_per_year = data['made'].value_counts().sort_index()
yearly_counts_dict = properties_per_year.to_dict()
data_1 = data.copy()
data_1['properties_built_in_year'] = data_1['made'].map(yearly_counts_dict)
It didn’t move the needle either, which I confirmed later during feature importance analysis — but I’m glad I tested it rather than assuming.
Next I ran boxplots across every numeric feature to check for extreme values:
numeric_columns = data.select_dtypes(include=np.number).columns.tolist()
n_cols = 4
n_rows = int(np.ceil(len(numeric_columns) / n_cols))
plt.figure(figsize=(n_cols * 4, n_rows * 3))
for i, variable in enumerate(numeric_columns):
plt.subplot(n_rows, n_cols, i + 1)
plt.boxplot(data[variable], whis=1.5)
plt.title(variable)
plt.tight_layout()
plt.show()
Here’s an honest moment: going in, I expected to find and have to treat real outliers — that’s the default assumption on any pricing dataset. What I actually found was boxes and whiskers that stretch cleanly from minimum to maximum with almost no points sitting beyond them. That’s consistent with everything else I’d found — a uniformly distributed, synthetic dataset simply doesn’t produce the kind of skewed extremes that trigger aggressive outlier treatment.
So I made a deliberate choice: I didn’t apply IQR clipping or truncation. On real housing data, an extreme value is often a legitimate luxury property, not a data entry error, and blindly clipping it teaches your model to ignore the high end of the market entirely. Since this dataset gave me no compelling statistical reason to clip anything, I left the values exactly as they were and moved straight into preprocessing.
With EDA done, I split features from target and applied standard scaling — but only where it would actually matter:
df = data.copy()
X = df.drop(columns=['price'])
y = df['price']
# Scaling is only needed for the linear model —
# tree-based models split on raw feature values, not distances
scaler = StandardScaler()
X_scaled = scaler.fit_transform(X)This is a small detail but an important one: Random Forest and XGBoost don’t care about feature magnitude — they split on thresholds. Linear Regression absolutely does care, because without scaling, a feature like squareMeters (values in the tens of thousands) would dominate the cost function over a binary feature like hasPool purely by virtue of its scale, not its actual importance.
I didn’t want to just train one model and call it done. I set up three candidates that represent genuinely different modeling philosophies, and let 5-fold cross-validation decide between them:
# Evaluation metrics
def rmse(y_true, y_pred):
return np.sqrt(mean_squared_error(y_true, y_pred))
scoring = {
'MAE': make_scorer(mean_absolute_error),
'RMSE': make_scorer(rmse),
'R2': make_scorer(r2_score)
}
# Candidate models
models = {
'Linear Regression': LinearRegression(),
'Random Forest': RandomForestRegressor(n_estimators=100, random_state=42),
'XGBoost': XGBRegressor(n_estimators=100, learning_rate=0.1, random_state=42)
}
kf = KFold(n_splits=5, shuffle=True, random_state=42)
results = []
for model_name, model in models.items():
X_input = X_scaled if model_name == 'Linear Regression' else X
mae_scores = cross_val_score(model, X_input, y, cv=kf, scoring=scoring['MAE'])
rmse_scores = cross_val_score(model, X_input, y, cv=kf, scoring=scoring['RMSE'])
r2_scores = cross_val_score(model, X_input, y, cv=kf, scoring=scoring['R2'])
results.append({
'Model': model_name,
'MAE': np.mean(mae_scores),
'RMSE': np.mean(rmse_scores),
'R²': np.mean(r2_scores)
})results_df = pd.DataFrame(results).sort_values(by='RMSE')
print(results_df)| Model | MAE | RMSE | R² | Notes |
|---|---|---|---|---|
|
Linear Regression |
1,481.15 |
1,900.21 |
1.000 |
Lowest error, fastest inference |
|
Random Forest |
3,094.42 |
3,875.56 |
1.000 |
2× the error of the baseline |
|
XGBoost |
10,608.38 |
12,640.22 |
1.000 |
Worst performer, ~7× the error |
FIELD NOTE
This result genuinely surprised me the first time I saw it. I went in assuming XGBoost, the algorithm that wins most Kaggle leaderboards, would come out on top or at least close. Instead it posted the worst error of the three — nearly seven times higher than plain old Linear Regression. All three models technically reported a perfect R² of 1.000, so on that metric alone they look tied. MAE and RMSE told the real story.
price = f(squareMeters) turned out to be here — a staircase is a worse approximation of a line than, well, an actual line. Linear Regression didn’t win because it’s a “simpler” or “safer” choice; it won because it was mathematically the correct tool for this specific data-generating process. To move past raw accuracy numbers and understand why the model was predicting what it was predicting, I fit a Decision Tree Regressor purely to extract feature importance scores:
X_1 = data.drop('price', axis=1)
y_1 = data['price']
X_encoded = pd.get_dummies(X_1, drop_first=True)
dt_model = DecisionTreeRegressor(random_state=42)
dt_model.fit(X_encoded, y)
importances = pd.Series(dt_model.feature_importances_, index=X_encoded.columns)
importances_sorted = importances.sort_values(ascending=False)
plt.figure(figsize=(10, 6))
sns.barplot(x=importances_sorted.values, y=importances_sorted.index, palette='viridis')
plt.title("Feature Importance (Decision Tree)")
plt.show()
squareMeters scored an importance close to 1.0. Everything else — floors, attic, garage, number of rooms, city part range, all the amenity flags — rounded down to almost nothing. This matched the correlation heatmap perfectly and closed the loop on my earlier hypothesis: this dataset has exactly one real driver of price, and I’d now confirmed it three separate ways — correlation, scatter plot, and model-native feature importance.
Knowing that cityCode, numPrevOwners, made, and hasGuestRoom carried effectively zero signal, I dropped them before training the version of the model I actually intended to ship. Fewer irrelevant dimensions means a smaller, faster, more maintainable model — no reason to serialize noise.
# Drop features with no meaningful correlation to price
data = data.drop(columns=['cityCode', 'numPrevOwners', 'made', 'hasGuestRoom'])
X = data.drop('price', axis=1)
y = data['price']
scaler = StandardScaler()
X_scaled = scaler.fit_transform(X)
kf = KFold(n_splits=5, shuffle=True, random_state=42)
model = LinearRegression()
mae_scores = cross_val_score(model, X_scaled, y, cv=kf, scoring=scoring['MAE'])
rmse_scores = cross_val_score(model, X_scaled, y, cv=kf, scoring=scoring['RMSE'])
r2_scores = cross_val_score(model, X_scaled, y, cv=kf, scoring=scoring['R2'])
print(f"Mean MAE : {np.mean(mae_scores):.2f}")
print(f"Mean RMSE: {np.mean(rmse_scores):.2f}")
print(f"Mean R² : {np.mean(r2_scores):.4f}")
model.fit(X_scaled, y)Almost identical to the 16-feature version — which is exactly what I wanted to see. Dropping four irrelevant columns cost nothing in accuracy and made the model leaner. With that confirmed, I trained on the full dataset and serialized both the model and the scaler with joblib:
import joblib
joblib.dump(model, 'house_price_model.pkl')
joblib.dump(scaler, 'scaler.pkl')
print("✅ Model and Scaler saved as .pkl files")Why joblib, not pickle
I used joblib instead of the standard library’s pickle because Scikit-Learn models are, under the hood, mostly NumPy arrays — model coefficients, in this case. Joblib is built to serialize large NumPy arrays efficiently, which keeps the resulting .pkl files smaller and faster to load. And critically: the scaler is just as important to serialize as the model. If I only saved the trained regression weights and forgot the scaler, every prediction at inference time would be computed on unscaled input — the model would silently produce meaningless numbers.
With house_price_model_1.pkl and scaler_1.pkl in hand, the next job was giving them a face. I chose Streamlit because it lets me turn a Python script into a working web form without touching HTML, CSS or JavaScript — perfect for a solo builder who wants to go from model to usable product fast.
import streamlit as st
import joblib
import numpy as np
model = joblib.load('house_price_model_1.pkl')
scaler = joblib.load('scaler_1.pkl')
st.title("🏠 House Price Prediction App By Nabankur Ray")
st.markdown("Enter property details below to predict the price.")I split the form into two columns for the numeric fields and a row of checkboxes for the amenities, so the whole thing fits on one screen without endless scrolling:
square_meters = st.number_input("Square Meters (Required)", min_value=20, max_value=99999, value=100, step=1)
col1, col2 = st.columns(2)
with col1:
num_rooms = st.slider("Number of Rooms", 1, 100, 3)
attic = st.slider("Attic Size (m²)", 0, 10000, 10)
garage = st.slider("Garage Size (m²)", 0, 1000, 10)
with col2:
floors = st.slider("Number of Floors", 1, 100, 1)
basement = st.slider("Basement Size (m²)", 0, 10000, 10)
city_part_range = st.selectbox("City Part Range (1 = Low, 10 = High)", list(range(1, 11)), index=4)
st.markdown("### Additional Features")
bcol1, bcol2, bcol3, bcol4, bcol5 = st.columns(5)
has_pool = bcol1.checkbox("Pool")
has_yard = bcol2.checkbox("Yard")
is_new = bcol3.checkbox("New")
has_storage = bcol4.checkbox("Storage Room")
has_storm_protector = bcol5.checkbox("Storm Protector")features = np.array([[
square_meters, num_rooms, floors, attic, basement, garage,
city_part_range, int(has_pool), int(has_yard), int(is_new),
int(has_storage), int(has_storm_protector)
]])
if st.button("Predict Price"):
expected_features = 12
if features.shape[1] != expected_features:
st.error(f"Expected {expected_features} features, but got {features.shape[1]}")
elif np.isnan(features).any():
st.error("Input contains missing values. Please complete all fields.")
else:
try:
input_scaled = scaler.transform(features)
prediction = model.predict(input_scaled)[0]
st.success(f"💰 Estimated House Price: ${prediction:,.2f}")
except Exception as e:
st.error(f"Prediction failed: {e}")I deliberately added the feature-count check and the NaN check before calling scaler.transform(). Streamlit apps get used by real people clicking real buttons in unpredictable order, and I’d rather show a clear, specific error message than let a malformed array crash silently or produce a nonsense price.
Getting a model working locally is one milestone; getting it in front of a stranger with zero setup on their end is a different one. Here’s the path I took:
- Pushed
app.py,house_price_model_1.pkl,scaler_1.pkl, and arequirements.txtlisting every dependency to a public GitHub repository. - Connected the repository to Streamlit Community Cloud and pointed it at
app.pyas the entry file. - Let Streamlit Cloud install dependencies automatically from
requirements.txtand build the app. - Tested every input combination on the live URL — sliders at their minimums and maximums, every checkbox toggled — before calling it done.
- Set up the repository so any future push to the connected branch triggers an automatic redeploy.
I want to flag something honestly rather than pretend everything went smoothly on the first try. When you scale features with StandardScaler, it doesn’t just remember the mean and standard deviation of each column — it remembers them in the exact column order you fit it on. My training pipeline built X in this order:
# Training-time column order
squareMeters, numberOfRooms, hasYard, hasPool, floors,
cityPartRange, isNewBuilt, hasStormProtector,
basement, attic, garage, hasStorageRoomBut when I built the input array inside the Streamlit app, I laid the widgets out in whatever order made sense for the UI — and the resulting array ended up in a different order:
# App-time array order
square_meters, num_rooms, floors, attic, basement, garage,
city_part_range, has_pool, has_yard, is_new,
has_storage, has_storm_protectorWHY THIS IS DANGEROUS
Both arrays have the right 12 values — nothing is missing, so no error gets raised anywhere. But scaler.transform() has no idea what each column “means”; it just applies the mean and standard deviation it learned for position 0, position 1, position 2, and so on. If the UI layout doesn’t match the exact training order, the scaler quietly normalizes the wrong feature against the wrong statistics, and the model returns a confident, fully-formed, completely wrong price — with no exception, no warning, nothing.
This is one of those bugs that’s invisible until you go looking for it, because everything “works.” My advice, and what I’d do differently starting this project again: save the exact training column order as a small JSON or Python list right next to the .pkl files, and have the app build its feature array by explicitly mapping widget values to that saved list — never by eyeballing the order while writing UI code. It’s a five-minute safeguard against a bug that’s genuinely hard to catch by testing, because plausible-looking wrong prices don’t look like bugs.
Everything above worked because this specific dataset is synthetic and, underneath the noise, essentially a straight line. I don’t want to overstate what this project proves. If I pointed this same pipeline at real MLS transaction records tomorrow, several things would have to change:
- Location needs real geospatial treatment. Dropping
cityCodewas correct here because it carried zero signal — but in a real market, location is often the single biggest price driver. I’d bring in latitude/longitude, distance to city center, school district quality, or transit proximity instead of a raw zip code. - Outliers need real scrutiny. A uniform, synthetic dataset let me skip aggressive outlier treatment. Organic housing data is full of legitimate extreme values — mansions, foreclosures, unique properties — that need careful IQR analysis or robust models rather than a blanket policy in either direction.
- Non-linearity should be expected, not the exception. Real price-to-size relationships bend — the marginal value of an extra 20 m² is not constant from a studio to a mansion. Tree-based models or gradient boosting would likely earn back the edge they lost here.
- An R² of 1.000 should worry you, not impress you. On real data, a perfect score is one of the strongest signals of target leakage you can get. I’d treat it as a debugging trigger, not a result to celebrate.
As next steps for this project specifically, I’m considering: wiring in a live property-listings feed instead of a static CSV, adding a lightweight image-based “condition score” using a small CNN, and eventually moving the backend off Streamlit Community Cloud toward a containerized FastAPI service for higher-throughput use.
The biggest lesson this project reinforced for me wasn’t about regression math — it was that a model’s job isn’t finished when the notebook prints a good R². Getting from a trained LinearRegression() object to something a stranger can actually use in their browser required thinking like a software engineer as much as a data scientist: serializing state correctly, matching preprocessing at inference time to preprocessing at training time, and building a UI that fails loudly and clearly instead of silently. A highly accurate model that nobody can access delivers exactly zero value. The version that’s live right now, sliders and all, is the one that actually does something.
FAQs ~
What is an Automated Valuation Model (AVM)?
It’s an algorithm that estimates real estate prices using historical property data instead of a manual, in-person appraisal. Lenders, brokerages and property platforms use AVMs to generate fast, consistent baseline valuations before (or instead of) a human appraisal.
Why did Linear Regression beat XGBoost here?
Because the underlying relationship in this dataset — price as a function of square meters — is almost perfectly linear. A straight-line model captures that instantly. Tree-based models like XGBoost approximate a slope with a staircase of splits, which adds error on a relationship that was never non-linear to begin with. This flips on genuinely non-linear, real-world data, where tree ensembles usually pull ahead.
How do you actually deploy a Scikit-Learn model to the web?
Serialize the trained model and any preprocessing objects — in this case a StandardScaler — using joblib. Load both inside a Streamlit script, connect input widgets to a feature array that matches the exact column order used during training, run scaler.transform() then model.predict(), and deploy the repository on Streamlit Community Cloud.
What does an R-squared of 1.0 actually mean?
It means the model explains 100% of the variance in the target variable. On real-world data, that’s almost always a red flag for target leakage — information from the target sneaking into the features. On a procedurally generated synthetic dataset like this one, it usually means the model successfully reverse-engineered the exact formula used to create the data.
Do I need to scale features before feeding them into a Streamlit ML app?
Yes, if the model was trained on scaled data — and you need to use the exact same fitted scaler object from training, not a freshly created one. Just as important: the feature order you pass into that scaler at inference time has to exactly match the column order used when the scaler was originally fit, or predictions will be silently wrong.
Add comment
You must be logged in to post a comment.