My Six Week Internship and Project Taught Much More!

What I Learned Building a Customer Churn Prediction System (and Why I Didn’t Stop There)

When I started my IT internship, I thought I knew roughly what I was signing up for: pick a dataset, train a model, write a report, done. Three months in, I can say with confidence that the “done” part never really arrived — and that turned out to be the best part of the experience.

My core project was Customer Churn Prediction using Machine Learning — building a system that could flag which customers were likely to leave a business before they actually did. On paper, it’s a classic supervised learning problem. In practice, it became a crash course in how much work happens around the model, not just inside it.

Week 1: Getting My Hands Dirty With the Data

Every churn project starts the same way: with a dataset that looks deceptively simple until you actually open it. My first week was spent on exploratory data analysis — understanding the customer features (contract type, tenure, monthly charges, support history), checking for class imbalance, and getting a feel for which columns might actually matter before I let any algorithm near them.

It wasn’t glamorous, but it set the tone for everything after it. I learned quickly that the time spent here is time you don’t lose later debugging a model that’s confidently wrong.

Week 2: Training the First Models

With cleaned data in hand, I moved into model building. I trained four different algorithms — Random Forest, Decision Tree, XGBoost, and LightGBM — and ran each through hyperparameter tuning and cross-validation rather than trusting a single train-test split.

XGBoost came out as the standout performer by the end of the week. That wasn’t a huge surprise in hindsight — it tends to do well on structured, tabular data like customer records — but watching it consistently beat the others across multiple validation folds made the result feel earned rather than assumed.

Week 3: Learning That Accuracy Isn’t the Finish Line

This is the week I expected to be “done” with modeling and instead realized I’d only finished the first half. A good accuracy score doesn’t mean much if you can’t explain why the model is making its decisions — especially when the output is meant to inform real business calls about which customers to retain.

That question pushed me into SHAP (SHapley Additive exPlanations) analysis — a method for understanding which features are actually driving a model’s predictions. Instead of treating XGBoost as a black box that spits out “this customer will churn,” SHAP let me show which factors were pushing that prediction one way or another, and by how much.

Week 4: Turning the Model Into Something Usable

Once I trusted the model’s reasoning, I wanted other people to be able to interact with it without opening a Jupyter notebook. So I spent this week building a Streamlit web app — an interface where someone can input customer details and get back a churn probability along with a visual breakdown of why.

This is also when I wrote up Weekly Report 4, covering both the SHAP analysis and the Streamlit app. It was the first week where I had something I could actually demo end-to-end, and that shift — from “here’s my code” to “here, try it yourself” — changed how the project felt.

Week 5: Deciding to Build Something Nobody Assigned Me

With the core ML pipeline in a solid place, I made a call that wasn’t strictly part of the internship scope: I wanted to understand where the data comes from before it ever reaches a model. So I started learning ETL (Extract, Transform, Load) from scratch — I had zero prior experience with it going in.

I kept the tools familiar on purpose: Python and Pandas for the logic, SQLite as the destination database. By the end of the week I had the extract and transform steps working — pulling in the raw customer data and reshaping it into something clean and consistent.

Week 6: Getting Data Into an Actual Database

This week was about finishing what I’d started: the load step. I got all 7,032 rows of transformed customer data into a proper SQLite database instead of leaving everything sitting in a CSV file.

It sounds like a small milestone, but it changed how I think about the churn project entirely. A model is only as good as the pipeline feeding it, and building that pipeline by hand — instead of just calling pd.read_csv() and moving on — made the "garbage in, garbage out" warning every ML course gives you feel concrete instead of theoretical.

What’s Next

As of now, I’m working through the next layer of the ETL side: writing SQL queries to pull actual business insights out of that database, consolidating everything into a single pipeline.py script instead of scattered notebooks, and setting up basic scheduling so the pipeline can run on its own. GitHub setup is on the list too, partly for version control and partly because I wanted this project to exist somewhere a recruiter could actually look at it. Cloud deployment is the next big milestone on the horizon for the core project as well.

Why I Bothered Building Something Nobody Assigned Me

If I’m honest, the ETL pipeline wasn’t on my original project brief. It came from a fairly simple realization: a “Customer Churn Prediction” project on a resume is common. A churn prediction project with an accompanying data engineering pipeline — one that shows you understand how data moves before it’s modeled — is a little less common. So I treated it as a deliberate skill investment rather than scope creep, and built it as a parallel track alongside the core ML work.

That decision turned my internship into two interleaved stories instead of one: a machine learning story (XGBoost, SHAP, Streamlit) and a data engineering story (extract, transform, load, SQL, automation). Writing weekly reports on both forced me to actually articulate what I’d done each week, which — more than any single technical skill — might be the habit I’m most grateful for. It’s easy to do work and much harder to explain it clearly, on a deadline, every week.

The Honest Takeaway

Nothing about this internship was glamorous in the way internship stories sometimes get told. There was no single breakthrough moment. It was Random Forest results compared against Decision Tree results, then against XGBoost and LightGBM. It was SHAP plots that needed a second look to interpret correctly. It was a Pandas transform script that failed silently three times before I figured out why.

But somewhere in that repetition, the pieces started fitting into something coherent: a project that can predict churn, explain its own reasoning, present that reasoning through an actual interface, and sit on top of a real pipeline that I built from raw data to database. That’s a more complete picture than the one I had in my head on day one — and it’s the version I’m proud to keep building.

If you’re starting an internship in ML or data and wondering whether to stick strictly to the assigned scope or chase the thing that seems useful but isn’t required — my answer, three months in, is: build the thing nobody assigned you. It’s usually the part you end up talking about the most.