DEV Community: zohir Benmalek

Building a Car Price Predictor with Scikit-learn and Flask

zohir Benmalek — Tue, 25 Aug 2026 16:46:43 +0000

Machine learning tutorials often end after model.fit(). But training a model is only one part of building a useful ML application.

A more interesting workflow is to take a dataset, prepare the data, engineer useful features, compare several models, save the best pipeline, and finally turn it into a web application.

That is what this car price predictor project does using Python, Pandas, Scikit-learn, Joblib, and Flask.

The complete walkthrough is available on SoftwareJournal.blog, while the project source code is available on GitHub.

The Architecture

The project follows a simple machine learning pipeline:

Dataset
   ↓
Data Cleaning
   ↓
Feature Engineering
   ↓
Preprocessing
   ↓
Model Training
   ↓
Model Evaluation
   ↓
Save Pipeline
   ↓
Flask Application
   ↓
Prediction

The repository contains a Jupyter notebook for experimentation and a Flask application for serving predictions.

car_price_predictor/
├── notebook.ipynb
├── README.md
└── car_price_predictor/
    ├── app.py
    ├── requirements.txt
    └── templates/
        └── index.html

Preparing the Dataset

The project uses a second-hand car dataset with fields such as manufacturer, model, engine size, fuel type, year, mileage, and price.

Pandas is used to load the CSV file:

import pandas as pd

df = pd.read_csv("car_sales_data.csv")

Before training anything, the notebook checks the dataset using methods such as:

df.isnull().sum()
df.info()

This is an important step in any machine learning project. Problems with missing values or unexpected data types are much easier to fix before the training pipeline is created.

Feature Engineering

One of the project's main transformations is converting the manufacturing year into the age of the car.

df["Age"] = 2024 - df["Year of manufacture"]

The original year column is then removed from the model inputs:

X = df.drop(columns=["Price", "Year of manufacture"])
y = df["Price"]

This gives the model a more directly meaningful feature: how old is the vehicle?

There is also an important caveat here. The reference year is hardcoded to 2024, so this should be changed to a dynamic calculation in a production application.

Preprocessing with Scikit-learn

The dataset contains both numerical and categorical features.

Numerical features include:

Engine size
Mileage
Age

Categorical features include:

Manufacturer
Fuel type
Model

Scikit-learn's ColumnTransformer makes it possible to process those columns differently.

from sklearn.compose import ColumnTransformer
from sklearn.preprocessing import StandardScaler, OneHotEncoder

preprocessor = ColumnTransformer(
    transformers=[
        ("num", StandardScaler(), numerical_features),
        ("cat", OneHotEncoder(handle_unknown="ignore"), categorical_features)
    ]
)

StandardScaler standardizes numerical values, while OneHotEncoder converts categories into numerical columns.

One particularly useful option is:

handle_unknown="ignore"

This means the application can encounter an unseen categorical value without immediately failing during prediction.

Why Pipeline Is So Useful

The preprocessing object is combined with the machine learning model:

from sklearn.pipeline import Pipeline

pipeline = Pipeline([
    ("preprocessor", preprocessor),
    ("regressor", model)
])

This is one of the best design choices in the project.

Instead of saving preprocessing logic separately from the trained model, the pipeline becomes one object containing the entire process.

That means the Flask application can later receive raw data and simply call:

pipeline.predict(input_data)

There is no need to manually perform scaling and one-hot encoding again.

This significantly reduces the risk of training-serving inconsistencies.

Comparing Four Models

The project evaluates four regression algorithms:

models = {
    "LinearRegression": LinearRegression(),
    "Ridge": Ridge(),
    "RandomForest": RandomForestRegressor(
        n_estimators=100,
        random_state=42,
        n_jobs=-1
    ),
    "GradientBoosting": GradientBoostingRegressor(
        n_estimators=100,
        random_state=42
    )
}

The dataset is divided into training and testing sets:

X_train, X_test, y_train, y_test = train_test_split(
    X,
    y,
    test_size=0.2,
    random_state=42
)

Each model is trained through the same preprocessing pipeline and evaluated using Mean Absolute Error (MAE) and R².

The reported results are:

Model	MAE	R²
Linear Regression	5786.31	0.7102
Ridge	5786.14	0.7102
Random Forest	286.04	0.9986
Gradient Boosting	1037.39	0.9899

Random Forest performs the best on this dataset.

The result is interesting because the linear models struggle to capture the nonlinear relationships between car age, mileage, manufacturer, model, and price.

Tree-based ensemble models are much better suited to that kind of relationship.

However, an R² of 0.9986 is exceptionally high. The dataset is a mock/synthetic dataset, so these numbers should not be interpreted as evidence that the same model would achieve similar accuracy on a real-world used-car market.

Saving the Models

Once the pipelines have been trained, Joblib is used to serialize them:

joblib.dump(
    pipeline,
    f"saved_models/{name}_pipeline.joblib"
)

This means the trained pipeline can be loaded later without running the complete training process again.

The winning Random Forest pipeline can then be reloaded:

loaded_pipeline = joblib.load(
    "saved_models/RandomForest_pipeline.joblib"
)

Testing the Saved Pipeline

Before connecting the model to Flask, the project tests the serialized pipeline with new examples.

For example:

new_data = pd.DataFrame({
    "Manufacturer": ["BMW", "Ford", "Toyota"],
    "Model": ["X5", "Focus", "Camry"],
    "Engine size": [4.4, 1.6, 2.5],
    "Fuel type": ["Gasoline", "Gasoline", "Hybrid"],
    "Mileage": [35000, 80000, 15000],
    "Age": [4, 7, 1]
})

predicted_prices = loaded_pipeline.predict(new_data)

This is a useful test because it verifies that the saved object can be loaded successfully and used with previously unseen input.

Connecting the Model to Flask

The next step is turning the trained model into a web application.

The Flask application loads the pipeline when the server starts:

model = joblib.load(
    "saved_models/RandomForest_pipeline.joblib"
)

The main route handles both page loading and form submission:

@app.route("/", methods=["GET", "POST"])
def home():
    ...

When the user submits the form, Flask retrieves values such as:

manufacturer = request.form.get("manufacturer")
model_name = request.form.get("model")
year = int(request.form.get("year"))
mileage = int(request.form.get("mileage"))
engine_size = float(request.form.get("engine_size"))
fuel_type = request.form.get("fuel_type")

The application then calculates the vehicle's age and creates a DataFrame using the same column structure used during training.

input_data = pd.DataFrame({
    "Manufacturer": [manufacturer],
    "Model": [model_name],
    "Engine size": [engine_size],
    "Fuel type": [fuel_type],
    "Mileage": [mileage],
    "Age": [age]
})

Finally:

prediction = model.predict(input_data)

The prediction is sent back to the HTML template and displayed to the user.

The Frontend

The application uses a straightforward HTML interface rendered with Jinja2 and styled with Bootstrap.

Instead of asking users to type arbitrary manufacturer and model names, the interface uses dropdowns.

That reduces typing mistakes and helps keep the input consistent with the categories the model was trained on.

The frontend does not require a JavaScript framework or a separate build process. Flask renders the page directly.

Running the Application

After installing the dependencies:

pip install -r requirements.txt

the application can be started with:

python car_price_predictor/app.py

The Flask development server will normally be available at:

http://127.0.0.1:5000

You can then enter the vehicle information and receive a predicted price through the browser.

What I Like About This Project

The most useful lesson here isn't the particular Random Forest model.

It is the structure of the project.

The same preprocessing pipeline is used during training and inference. Multiple algorithms are compared instead of assuming the first model will be good enough. The trained pipeline is persisted so it can be reused later. Finally, Flask provides a simple interface between the model and an ordinary web user.

That is a much more realistic machine learning workflow than a notebook that simply prints an accuracy score.

What Could Be Improved?

There are several improvements that would make this project stronger for production use.

The 2024 reference year should be calculated dynamically rather than hardcoded.

Cross-validation and hyperparameter tuning could provide more reliable model evaluation than relying on a single train/test split.

The Flask form could also have stronger validation for invalid or missing values.

Another improvement would be moving feature engineering into shared Python code so that the notebook and Flask application cannot accidentally implement different versions of the same transformation.

Final Thoughts

This car price predictor is a good example of how a relatively small Python project can connect several important areas of development:

Pandas handles the data.

Scikit-learn handles preprocessing and machine learning.

Pipeline keeps transformations and prediction together.

Joblib stores the trained model.

Flask exposes the model through a web application.

The result is a complete path from dataset to browser:

Raw Data
→ Machine Learning
→ Saved Pipeline
→ Flask
→ Web Prediction

For developers learning machine learning deployment, this is often the step that makes everything click: the model isn't the entire application. It is one component inside a larger software system.

You can find the original technical walkthrough on SoftwareJournal.blog and the complete source code on GitHub.

Originally published on SoftwareJournal.blog.

I Started a Blog About Software Because I Like Taking Things Apart

zohir Benmalek — Sun, 23 Aug 2026 21:44:41 +0000

I've always found it more interesting to understand why something works than to just use it.

When you use an application, you usually don't think about what's happening underneath. You click a button, something loads, data gets saved, an API returns a response, and you move on.

But as a developer, I tend to wonder about the stuff behind that button.

How was it built?

Why did the developer choose that database?

Why this framework instead of another one?

What happens when the application gets bigger?

What happens when something breaks?

And, probably most importantly, what can I learn from it?

That's basically why I started Software Journal.

👉 softwarejournal.blog

So, what is Software Journal?

It's a small independent software and technology publication where I write about things I'm interested in building, using, and understanding.

There's no complicated concept behind it.

I just wanted a place where I could write about software without everything having to fit into a short tutorial or a "10 best tools" article.

Some articles are about programming.

Some are about AI.

Some are about databases or security.

Others are simply breakdowns of interesting projects.

The common theme is software and the things around it.

I like learning by building

One thing I've noticed about programming is that reading documentation only gets you so far.

You can read about SQLite for an hour and understand the basic API.

Then you build something that actually uses SQLite and suddenly you discover ten new things you didn't think about.

The same thing happens with AI.

It's easy to write:

response = model.generate(...)

But building a real application around that call is a completely different experience.

You have to think about errors, user input, data, security, interfaces, costs, deployment, and everything else that isn't visible in the first few lines of code.

That's the kind of stuff I like exploring.

Some of the projects I write about

I've written about projects using technologies such as Python, Flask, SQLite, Tkinter, NumPy, SciPy, and Google Gemini.

For example, I've looked at projects involving things like:

AI-powered applications
Desktop applications
Database tools
Scheduling and optimization
Security-related utilities
Web applications

What I find interesting isn't just the final result.

It's the decisions that went into getting there.

A small project can actually teach you a lot about software engineering when you take the time to look at how all the pieces fit together.

I'm not trying to create another "AI news" website

AI is obviously a huge part of software right now, and I'll probably write about it quite a bit.

But I don't want Software Journal to become another site that publishes an article every time an AI company releases something.

I'm much more interested in the practical side.

What can you actually build with these technologies?

How do these applications work?

What are the limitations?

What happens when the demo becomes a real product?

Those questions are much more interesting to me.

Sometimes the simplest projects are the best

I've also started to appreciate something that I probably overlooked earlier:

You don't always need a huge project to learn something useful.

A small SQLite application can teach you about data persistence.

A simple desktop application can teach you about UI state.

A tiny API can teach you about authentication and error handling.

A basic AI experiment can teach you about prompting, embeddings, or model limitations.

You don't need to build the next billion-user platform to learn something valuable.

Sometimes a weekend project is enough.

Why the name "Software Journal"?

Honestly, because that's what I want it to feel like.

A journal.

Not a corporate publication trying to predict the future of technology.

Not a news site chasing every trend.

Just a growing collection of things I've learned, interesting software I've found, projects I've worked with, and ideas worth exploring.

Some articles will probably be better than others.

Some experiments will fail.

Some technologies that seem exciting today will probably be forgotten later.

That's fine.

The point is to keep learning and document some of that process.

There's a lot more I want to explore

There are still a ridiculous number of things in software that I want to understand better.

Distributed systems.

Better database design.

AI agents.

Search and retrieval.

Compilers.

Networking.

Security.

Infrastructure.

Different programming languages.

Open-source projects.

And a lot of things I haven't even discovered yet.

So Software Journal is still very much a work in progress.

I'm basically building the library while I'm learning.

If you're curious too

If you enjoy programming, experimenting with new technologies, reading about how applications work, or simply taking software apart to see what's inside, you might find something interesting there.

You can start here:

Software Journal

Or browse the articles directly:

https://softwarejournal.blog/blog/

I don't know exactly what Software Journal will look like a year from now.

That's actually part of the fun.

For now, I'm just going to keep building things, breaking things, learning things, and writing about them.

4u.lat: A Practical Hub for Discovering AI Tools, Software, and Better Ways to Work

zohir Benmalek — Tue, 18 Aug 2026 00:53:59 +0000

The world of artificial intelligence is moving incredibly fast. New models, applications, automation platforms, coding assistants, creative tools, and productivity solutions appear almost every day. For people trying to keep up, the biggest challenge is no longer finding AI tools—it is finding the right tools and understanding how they can actually be useful.

That is where 4u.lat comes in.

4u.lat is a website dedicated to discovering and exploring AI tools, software, and practical technology guides, bringing useful information together in one place. Instead of forcing visitors to search through countless websites to understand what a tool does or whether it is worth trying, the platform aims to make that discovery process simpler, faster, and more useful.

A Place to Discover What AI Can Actually Do

AI is no longer limited to chatbots. Today, there are tools for writing, programming, image generation, video creation, automation, research, productivity, business, and much more.

4u.lat organizes this rapidly expanding ecosystem into understandable categories, making it easier for visitors to discover technologies that match their needs.

Whether someone is looking for an AI coding assistant, an image-generation platform, an automation solution, a writing tool, or a new AI model to experiment with, the goal is the same: help people discover useful technology without unnecessary complexity.

More Than a List of AI Tools

One of the most valuable aspects of an AI-focused website is context.

Simply knowing that a tool exists is not enough. People want to know what it does, who it is for, what makes it interesting, and how it can be used in the real world.

That is why 4u.lat goes beyond simply collecting names and links. Its content can help turn technical developments into information that ordinary users, developers, creators, and technology enthusiasts can understand.

The result is a more practical approach to AI discovery: instead of asking “What AI tools exist?”, visitors can start asking “Which tool can solve my problem?”

Covering Different Areas of Modern AI

The AI ecosystem is incredibly diverse, and 4u.lat reflects that diversity through different areas of technology.

The site focuses on categories such as AI tools, AI coding, AI image generation, AI video, AI writing, AI productivity, AI automation, AI agents, AI news, and tutorials.

This makes the platform useful for different types of visitors.

A developer may discover a new coding model. A content creator may find an image or video generator. Someone building a business may discover an automation platform. A technology enthusiast may use the site to follow new developments in AI.

This broad coverage also makes 4u.lat more than a website dedicated to a single AI product or trend. It is designed around the larger ecosystem.

Helping People Keep Up With a Fast-Moving Industry

Perhaps the biggest reason a platform like 4u.lat is useful is the speed at which AI changes.

A tool that seems revolutionary today can be replaced by something better tomorrow. New models constantly improve coding, reasoning, image generation, video, speech, and automation capabilities.

For users, this creates information overload.

4u.lat can serve as a starting point for navigating that environment by highlighting interesting tools, technologies, and developments without requiring visitors to follow every AI company, model release, and technical announcement themselves.

Practical Guides, Not Just Hype

AI has generated enormous amounts of excitement, but useful technology should ultimately solve real problems.

Practical guides can help bridge the gap between an impressive AI announcement and actual usage. Instead of simply explaining that a new model exists, good guides can show readers how the technology fits into everyday workflows.

For example, someone might discover an AI coding tool and then learn how it can be incorporated into a development workflow. Another visitor might find an automation platform and discover ways to eliminate repetitive tasks.

That practical perspective is important because the value of AI is not only in what the technology can theoretically do—it is in what people can accomplish with it.

Built for Curious Users

4u.lat is particularly relevant to people who enjoy experimenting with new technology.

The AI industry rewards curiosity. Trying a new model, discovering a new application, or learning a new workflow can sometimes lead to significant improvements in productivity or creativity.

A website that brings those discoveries together can become a useful reference point for anyone who wants to stay ahead of the curve.

From beginners exploring AI for the first time to experienced users searching for their next tool, the platform is positioned around one simple idea: make modern technology easier to discover and understand.

The Future of 4u.lat

As artificial intelligence continues to develop, websites dedicated to discovering and explaining these technologies will become increasingly valuable.

The AI ecosystem is growing too quickly for most people to follow everything. Platforms such as 4u.lat can help reduce that complexity by filtering, organizing, and presenting useful information in a way that people can actually use.

The long-term potential is bigger than simply building a directory of AI products. It is about creating a destination where people can discover new technologies, learn how they work, and find better ways to use them.

Why 4u.lat Is Worth Watching

4u.lat represents a simple but increasingly important idea: technology discovery should be easier.

With AI evolving at an unprecedented pace, there is enormous value in having a dedicated place to explore new tools, follow important developments, and learn practical ways to use modern software.

Whether you are a developer, creator, entrepreneur, student, technology enthusiast, or simply someone curious about what AI can do, 4u.lat offers a gateway into a rapidly changing technological landscape.

4u.lat is not just about what AI can do today. It is about helping people discover what they can do with it next.

I’m building TWS, a small platform for audio-visual storytelling

zohir Benmalek — Sun, 16 Aug 2026 18:52:19 +0000

Hey everyone,

I’m building The Whispering Stories (TWS) — a small independent project at https://tws.rest/.

The idea came from wanting to experiment with a different way of consuming short stories.

Instead of presenting a story as a normal page of text, TWS combines writing, narration, and visual scenes into one experience.

You can read the story yourself, or listen to the narration while the scenes change as the story progresses.

Why I started it

I’ve always found the boundary between books, podcasts, and video interesting.

A book gives you complete control over the pace, but everything is left to your imagination.

A podcast gives you narration and atmosphere, but the visual side is mostly absent.

Video gives you text, audio, and visuals together, but the creator controls almost the entire pace.

I wanted to experiment somewhere in the middle.

With TWS, each story is broken into scenes, with the text, audio, and imagery connected to those scenes.

The technical challenge

The interesting part of the project hasn't really been making another website.

The harder problem is coordinating all of the content.

A single story can have:

The written narrative
Individual scenes
Images for each scene
Narration
Timing information
Metadata for the website

Those assets need to stay synchronized and load efficiently in the browser.

I’ve been building the project around a fairly simple web stack and gradually adding the infrastructure needed to handle the content.

Keeping the experience simple

I don't want TWS to become another social network or infinite-scroll content site.

The goal is much simpler:

Open a story → start reading or listening → experience the story.

There are no complicated workflows required to understand what the website is for.

That simplicity is something I’m trying to preserve as the project grows.

The part I'm still figuring out

The biggest question for me is whether combining these formats actually makes stories better.

There are obvious advantages.

A visual scene can establish a location immediately. Narration can make the experience more immersive. Text gives the reader control.

But there are also potential problems.

Too many visual changes could become distracting. Narration might feel too slow or too fast. Images might interfere with the reader's imagination rather than enhance it.

So I'm treating TWS as an ongoing experiment rather than pretending I've already found the perfect format.

What's next

I'm planning to keep expanding the story library while improving the actual reading/listening experience.

Some of the areas I'm particularly interested in are better synchronization between narration and scenes, improving performance, making the interface more accessible, and eventually making the storytelling format more interactive.

At this stage, I'm mainly looking for feedback from other indie hackers.

Does this combination of text + narration + visual scenes feel useful to you, or does it feel like unnecessary complexity compared with simply reading a story?

The project is live here:

https://tws.rest/

I'd love to hear what you think, especially from people who have built content platforms, media projects, or small consumer products themselves.