DEV Community: Mustapha Yusuf

Predicting Socioeconomic Status with Machine Learning: Building an End to End ML App

Mustapha Yusuf — Mon, 17 Aug 2026 15:18:29 +0000

Socioeconomic status is at the heart of everything we do in life from healthcare access to education to housing. And historically it has been measured by surveys which are slow, expensive, and prone to self-report bias. For my MSc Data Science dissertation at the University of Hertfordshire, I wanted to explore whether machine learning could be a faster, more scalable alternative to census data.
I used Folktables, an open source Python library that pulls curated, cleaned data directly from the US Census Bureau's American Community Survey. This eliminates a lot of the noise you get with self reported survey data, and it's fully reproducible since anyone can pull the same dataset.
The goal was to predict if an individual's income is above or below 50000 dollars a year, based on age, education level, occupation, hours worked per week, marital status, and sex.
I trained and tuned three classifiers.
Logistic regression as a fast and interpretable baseline. Random forest for a stronger nonlinear model. Gradient Boosting for the best possible predictive performance.
Each was scored in accuracy, precision, recall, F1 score, and AUC ROC. The linear model used Recursive Feature Elimination for feature selection, while the tree based models used feature importance scores.

The Results

Gradient Boosting was the best at 80 percent accuracy and an AUC of 0.88. Random Forest was close with an AUC of 0.87 and Logistic Regression was third at 0.81, as it failed to capture the nonlinear relationships of the data.

The five most important features of all models were occupation, education level, age, hours worked per week, and sex in line with current sociological research on income inequality.

Deployment
I didn’t want this to be another notebook that never gets used again. So I built a Flask web app around the final Gradient Boosting model, with a clean interface where anyone can enter a few demographic details and get a real time prediction. It’s deployed on Replit.
The next step is to focus on fairness. Any model for predicting income from demographic data must be very sensitive to bias, especially around protected characteristics. That’s something I’d like to explore further, possibly using the same Folktables framework to test fairness metrics across different demographic groups.

The full paper is openly published with a DOI through Zenodo and the code is on GitHub if you want to see the methodology or build on it.

Paper: https://doi.org/10.5281/zenodo.21963185
Code: https://github.com/Mustaphayinka/Msc_Data_Science_Project

I would really like to talk to anyone working on fairness-aware ML or applied data science more generally. Feedback and critique are welcome.

Why Economists Might Actually Make Better Data Scientists

Mustapha Yusuf — Mon, 10 Aug 2026 15:42:36 +0000

I built a small app called StatMate (getstatmate.com), and while working on it I kept running into the same realization over and over. A lot of data science is econometrics wearing a different name tag. Nobody tells economists this early enough, and I think it's part of why so many of them assume data science is some separate, more advanced world they're not qualified to enter.

It isn't. It's mostly the same tools with a rebrand.

Same math, different vocabulary

If you studied economics, you already know linear regression and logistic regression. You just learned them as core parts of econometrics, not as "machine learning algorithms," which is what the data science world calls them. Same equations. Same assumptions. Different label on the box.

It goes further than that. In economics, when you run a regression, you talk about independent variables and dependent variables. In data science, the exact same thing gets called features and labels, or features and the target variable. It's not a different concept. It's a different dialect for describing the same relationship between inputs and an outcome.

A few more that trip people up:

In econometrics you talk about coefficients. In data science, people call the same numbers weights or parameters, especially once you're working with anything beyond a simple regression.

Economists estimate a model. Data scientists train a model. Same process, fitting a function to data so it predicts well, just described with a different verb.

Economists check goodness of fit, often with R squared. Data scientists check model performance using accuracy, precision, recall, or other evaluation metrics depending on the problem. Different names, same underlying question: how well does this thing actually predict reality.

Multicollinearity is a term every economics student learns to fear. In data science, the same problem shows up as feature correlation or redundant features, and it causes the exact same headaches.

Even overfitting, one of the most talked about problems in machine learning, is something econometrics has dealt with for decades under different framing, usually tied to model specification and out of sample prediction.

Where economists actually have an edge

Here's the part that gets overlooked. Economists are trained to obsess over causality, not just correlation. Concepts like instrumental variables, difference in differences, and regression discontinuity exist because economists were forced to ask a harder question than "does this predict well." They had to ask "does this actually cause the outcome, or are we fooling ourselves with a pattern in the data."

A lot of data science, especially outside of causal inference specific work, is comfortable stopping at prediction. Economists are trained to be suspicious of prediction until they've ruled out confounding variables and reverse causality. That instinct alone is worth more than people give it credit for.

Why this matters

I think the real issue is that economics students rarely get told, explicitly, that they already have the statistical foundation for data science. They learn regression, hypothesis testing, and causal reasoning inside an economics classroom, then look at a data science job posting and see words like features, labels, and model training, and assume they're starting from zero.

They're not starting from zero. They're starting from a translation problem.

If more economists understood that machine learning algorithm often just means regression with a new name, and that a feature is just an independent variable that got renamed somewhere along the way, the field would feel a lot less intimidating to walk into. Data science is broader than econometrics, no argument there, but the core statistical spine underneath a huge amount of it is something economists already know cold.

That gap between the two vocabularies is part of what pushed me to build StatMate in the first place, something that makes the statistical side of this world less about memorizing new terminology and more about actually understanding what's happening underneath it.

If the tools are the actual blocker

Half the time, it's not even the concepts that scare people off. It's the tools. Someone understands regression perfectly well from their economics degree, then opens up a statistical package with a wall of syntax and menus and suddenly feels like a beginner again, even though the stats knowledge was never the problem.

That's the specific gap I built StatMate (getstatmate.com) to close. If you already get the underlying logic, whether from economics, econometrics, or just self study, and the thing holding you back is fighting with clunky statistical software instead of actually working with your data, it's worth a look. The goal was to strip out the friction and let the statistics speak for themselves instead of getting buried under a difficult interface.

I work on AI training and evaluation, and I built StatMate (getstatmate.com), a tool aimed at making statistical analysis more approachable for people crossing over from fields like economics into data driven work.

Why Accuracy Is the Hardest Thing to Get Right When Training AI

Mustapha Yusuf — Mon, 10 Aug 2026 15:27:52 +0000

I've spent the last while evaluating AI model outputs as part of training and fine tuning work, and if there's one thing that surprised me, it's this: accuracy breaks more often than anything else, and it breaks in ways that are easy to miss if you're not paying close attention.

When you evaluate AI responses at scale, you're usually working against a handful of core criteria. In my case it came down to four: accuracy, efficiency and instruction following. Each one sounds simple on paper. In practice, they pull against each other constantly, and accuracy is the one that quietly fails the most.

The problem with "sounding right"

A model can produce a response that reads as confident, well structured, and fluent, while being factually wrong or subtly off. This is the part that's hard to explain to anyone who hasn't sat with hundreds of outputs and had to mark them line by line. The model isn't lying. It's pattern matching its way to something plausible. And plausible is not the same as correct.

What I noticed reviewing output after output is that accuracy failures rarely look like obvious mistakes. They look like small, confident errors buried inside otherwise solid answers. A slightly wrong number in a calculation. A citation that sounds real but isn't. A code snippet that runs but solves a subtly different problem than the one asked. These are the failures that are easy to approve if you're moving fast, and that's exactly why careful evaluation matters so much.

Instruction following versus accuracy: a real tension

One thing that took me longer to appreciate is how instruction following and accuracy can actually work against each other. A model that follows instructions rigidly might produce an answer that technically does what was asked, while ignoring context that would have made the answer actually useful or correct. On the flip side, a model trying too hard to be "accurate" or thorough sometimes drifts away from what was actually requested.

Getting both right at once, doing exactly what was asked while also being factually solid, turned out to be one of the harder things to consistently reward during evaluation. It's not a binary pass or fail. It's a judgment call, every single time, and that judgment call is where a lot of the real work in AI training actually happens.

Efficiency is not a nice to have

Efficiency gets talked about less than accuracy, but it matters more than people assume. A response can be accurate and still be a bad response if it buries the answer inside three paragraphs of padding. Part of evaluating AI output well is recognizing when a model is technically correct but has failed to actually communicate that correctness clearly. Rewarding concise, direct answers over long winded ones is its own skill, and it's one that directly shapes how useful a model feels in practice.

What this taught me

If I had to summarize the biggest lesson from this work, it's that accuracy in AI systems isn't a single checkbox. It's the result of dozens of small, careful judgment calls made consistently over time by people who are willing to slow down and actually read the output in front of them rather than skim for a vibe. The models that improve are the ones being evaluated by people who catch the quiet failures, not just the obvious ones.

It's easy to assume AI training is mostly a technical, automated process. A meaningful part of it is still human judgment, applied one response at a time, and accuracy is where that judgment is tested the most.

I work on AI model evaluation and training, focused on output quality across accuracy, instruction following, and efficiency. Always interested in conversations with others doing similar work.

I built a free tool that runs real regressions for students who can't afford Stata

Mustapha Yusuf — Tue, 28 Jul 2026 17:34:21 +0000

A few months ago I started building something small and it's turned into the most useful thing I've shipped in a while, so I wanted to write up how it actually works, since a lot of the interesting decisions were in what I didn't build rather than what I did.

The problem, briefly

When I was doing my economics degree, a good chunk of the class either couldn't afford Stata or EViews, or had it installed and running but genuinely didn't understand what the output meant. Durbin-Watson, Breusch-Pagan, VIF — these get taught for maybe one lecture and then you're expected to just know how to read them for the rest of your degree. And your supervisor has thirty other students, so they can't sit with you through every regression you run.

So I built GetStatMate. You upload your data, tell it what you're testing (does X affect Y, a yes/no outcome, or something over time), it runs the actual statistical test, and it explains what came out in plain English instead of just spitting numbers at you.

It's live at getstatmate.com and the code's on GitHub if you want to poke at it.

The stack

Frontend's just HTML, JS, and Tailwind, sitting on Netlify. Backend's FastAPI on Render, and the actual statistics run through statsmodels, not anything I wrote myself. That last part matters more than it sounds — I'll get to why.

The part I actually spent time on: not letting anything guess a number

Here's the decision that shaped basically everything else about the project. When I got to the part where GetStatMate explains the results in plain economic language, the obvious move is to throw the numbers at an LLM and ask it to write something nice.

I didn't do that. Every explanation is built from a template engine with conditional logic — check the R-squared band, check which p-value threshold a coefficient falls under, check which diagnostics failed — and stitch together sentences from that. No language model touches the actual interpretation.

Why. Because an LLM narrating freely can restate a coefficient slightly wrong and sound completely confident doing it. For a tool students are trusting with an actual grade, "confidently wrong" is worse than "boring but correct." The template can only ever say what its logic explicitly allows, built directly off numbers that already came out of a real regression. It literally cannot invent a result.

A snippet of what that looks like, since code's more honest than a description:

def _sig_label(p):
    if p is None:
        return "not testable"
    if p < 0.01:
        return "significant at the 1% level"
    if p < 0.05:
        return "significant at the 5% level"
    if p < 0.10:
        return "significant at the 10% level"
    return "not statistically significant"

Nothing clever. That's the point.

Handling three different kinds of questions

Students don't all need the same test. So the question type a student picks routes to a genuinely different engine:

"Does X affect Y" → OLS, with the full diagnostic battery (Breusch-Pagan for heteroskedasticity, VIF for multicollinearity, Durbin-Watson for autocorrelation, Jarque-Bera for normality)
"Does X affect the probability of Y" → logistic regression, reporting odds ratios and a pseudo R-squared instead of the OLS diagnostics, which don't apply here
"Does X affect Y over time" → runs an Augmented Dickey-Fuller stationarity test on every variable before the regression, because regressing one trending series on another gives you a spurious, meaningless R-squared that looks great and means nothing

That last one is probably the thing I'm proudest of getting right. It's an easy mistake for a student to make and a genuinely common one in real undergrad time-series projects — running a regression on two things that are both just trending upward and mistaking the fit for a real relationship.

What breaks, and how I handle it breaking

Early versions of this just let a raw exception surface if someone picked a text column as their Y variable, or picked the same column for both X and Y. That's a bad experience for a non-technical user, so the validation layer now catches these specifically and returns a plain sentence instead of a stack trace — "this column contains text, not numbers" rather than a ValueError traceback.

There's also a genuinely fun one: when X variables are perfectly correlated, statsmodels throws a LinAlgError because the underlying matrix becomes singular. Caught that one specifically too, since it's a real and common student mistake, not a bug in my code.

What's next

Getting real students and lecturers to actually use it and tell me what's broken matters more right now than adding features. I've got a WhatsApp reply I'm hoping for from my department head, and I posted this on LinkedIn hoping a few coursemates mid-project would try it on real data.

Longer term: panel data support, cointegration testing for the time series path, and probably a downloadable report format so the output can go straight into an actual project write-up instead of living only on screen.

If you're a student, a lecturer, or just enjoy seeing what other people build, I'd genuinely like feedback: getstatmate.com, repo's here.