A team I worked with spent four months building a churn prediction model. It reached 0.87 AUC, which everyone agreed was good. It was never used. The reason was mundane: the model needed six features that only existed in a warehouse table refreshed weekly, and the retention team made their calls daily. Nobody had asked when the predictions would be needed until the model already existed.
I am a backend engineer, not a research scientist. My job in machine learning projects is usually the part after the notebook — getting a model into a system where it does something. From that seat you notice that the failures cluster in a very specific place, and it is almost never the algorithm.
So this is a practical tour of machine learning: what the main categories actually mean, which algorithms are worth your time, and the things that decide whether a project ships.
Supervised and Unsupervised, Without the Textbook Fog
Supervised learning means you have examples with the answer attached. A thousand emails labelled spam or not spam. Five years of houses with their sale prices. The model learns the mapping from inputs to that known answer, and you can measure how well it did, because you can hold back some examples and check.
This is where the overwhelming majority of useful business ML lives. Will this customer churn? Is this transaction fraudulent? How many units will we sell next month? What category does this ticket belong to?
Unsupervised learning means you have data with no answer attached and you want structure out of it. Clustering customers into segments nobody defined in advance. Reducing 200 columns to the handful that carry the signal. Flagging the transactions that look unlike everything else.
The catch with unsupervised work is that there is no score to point at. A clustering that produces five neat groups is not automatically right; you have to look at the groups and decide whether they mean anything. I have seen a customer segmentation project produce clusters that turned out to correspond almost exactly to which country's date format the signup form had used. The maths was fine. The conclusion was nonsense.
There is a practical middle ground people forget: you can often create labels. Business rules, historical outcomes, or a few hours of manual labelling by someone who knows the domain will turn a vague unsupervised problem into a measurable supervised one. That trade — a day of labelling for a metric you can actually optimise — is almost always worth making.
The Algorithms Worth Knowing First
The list of algorithms is long and the list of algorithms that solve real business problems is short. If you learn these properly you can handle most of what comes up:
Linear and logistic regression. Unfashionable, fast, and interpretable enough to explain to a stakeholder. Always your baseline. If a gradient boosted forest beats logistic regression by two points, you have learned something useful about whether the extra complexity is worth it.
Decision trees and random forests. Handle non-linear relationships and mixed data types without much preparation. A single tree is easy to visualise, which makes it a good teaching tool even when you deploy something else.
Gradient boosting — XGBoost, LightGBM, CatBoost. This is the workhorse for tabular data and it is not close. If your data is rows and columns, start here and expect to stay here.
k-means and DBSCAN for clustering. k-means is fast and assumes round, similar-sized groups; DBSCAN finds oddly-shaped ones and does not need you to pick the number of clusters up front.
PCA for dimensionality reduction, mostly as a diagnostic and preprocessing step.
Neural networks have a genuine place — images, audio, text, anything with sequence or spatial structure. For a spreadsheet of customer attributes, they usually lose to gradient boosting while costing more to train and far more to explain.
The Python Stack, Kept Small
You need less than the course catalogue suggests. pandas or polars for data handling, scikit-learn for the modelling and evaluation machinery, one boosting library, and matplotlib to look at things. That covers a large fraction of applied work.
from sklearn.model_selection import train_test_split
from sklearn.metrics import classification_report
from lightgbm import LGBMClassifier
X_train, X_test, y_train, y_test = train_test_split(
X, y, test_size=0.2, stratify=y, random_state=42
)
model = LGBMClassifier(n_estimators=400, learning_rate=0.05)
model.fit(X_train, y_train)
print(classification_report(y_test, model.predict(X_test)))
Two details in there matter more than any hyperparameter. stratify=y keeps the class balance the same in both splits, which you need whenever the positive class is rare. And classification_report instead of accuracy, because accuracy on an imbalanced problem is a trap — a model that predicts "not fraud" every single time is 99.7% accurate and completely worthless.
Where Projects Actually Die
Leakage. The number one cause of a model that performs beautifully in testing and terribly in production. Something in your training data encodes the answer in a way that will not exist at prediction time. A cancellation_reason column in a churn model. A timestamp that is only populated after the event you are predicting. Aggregates computed over the full dataset before splitting. The tell is a suspiciously good score, and the correct response to a suspiciously good score is suspicion.
Splitting time series randomly. If your data has a time dimension, a random split lets the model learn from the future to predict the past. Split by date. Always.
Feature availability at inference. The one that killed the churn project. Every feature has to be computable at the moment you need the prediction, with the latency the use case allows. Write that constraint down before you engineer a single feature.
Optimising the wrong metric. The business cares about the cost of a mistake, and mistakes are rarely symmetric. Missing a fraudulent transaction costs a hundred times more than flagging a legitimate one for review. Tune the decision threshold against that cost, not against a default of 0.5.
Nobody owning the model after launch. Data drifts. The model that was calibrated on last year's customers slowly stops matching this year's. Without monitoring — prediction distributions, input distributions, actual outcomes when they arrive — you will not notice until someone complains.
Deployment Is Mostly Ordinary Engineering
The part I get called in for is less exotic than people expect. A model is a function; wrap it in an API, or run it as a batch job that writes predictions to a table. Batch is underrated — if your consumer reads predictions once a day, you do not need a real-time inference service and all the operational weight that comes with it.
What does need care: pin the versions of everything, because a model trained with one library version and served with another can produce different numbers silently. Save the exact preprocessing alongside the model, since a feature scaled one way in training and another way in serving is a bug nobody finds for weeks. Log every prediction with its inputs, so that when someone disputes a decision you can reconstruct it. And keep the previous model deployable, because rollback matters here too.
Where Language Models Changed the Picture
It is worth being precise about this, because the hype has flattened a real distinction.
For tabular prediction problems — churn, forecasting, credit scoring, anomaly detection — classical ML is still the right answer and is not being displaced. Gradient boosting on structured data remains cheaper, faster, more accurate and far easier to explain to a regulator.
What changed is unstructured input. Text classification used to mean building a labelled dataset and training a model, a project measured in weeks. Now a well-specified prompt with a schema handles it in an afternoon, and often well enough to ship. Sentiment, categorisation, extraction from documents, routing free-text requests — those are no longer machine learning projects in the traditional sense.
The sensible pattern I keep landing on is a hybrid: use a language model to turn messy input into clean structured features, and a classical model to make the actual prediction from those features. You get the flexibility of one and the predictability, speed and cost profile of the other.
If You Are Starting a Project
Write down the decision the prediction will change, and who makes it, and how often. Then work backwards to what data must exist at that moment. Build the dumbest possible baseline first — even a business rule — and measure it, because if the baseline is nearly as good, you have saved yourself four months.
The best machine learning projects I have been part of were not the ones with the cleverest models. They were the ones where somebody asked, early and out loud, what would happen to the prediction after it was made.
