23 September 2026 · 7 min read · projectscareers

How to choose a machine learning project

A good machine learning project usually starts from a problem you or someone close to you actually has. This post covers where to find one, the questions to ask before you start, and what a project needs to be worth showing: a baseline, more than one dataset, more than one model, and more than one way to evaluate it.

A good machine learning project usually starts from a problem you care about: something that annoys you, something a friend or family member struggles with, or something you find fun. Projects picked from a "top 10 ML projects" list tend to stall halfway, and the ones that do get finished look like thousands of others. A problem you care about gives you a reason to finish, data that behaves like real data, and a story to tell when an interviewer asks why you built it.

Why a project list is a weak starting point

Most lists point to the same few datasets: Titanic survival, MNIST digits, house prices. Those are fine for learning a library in an afternoon. As a project they have three problems. There is no real question behind them, so nobody is waiting for the answer. The data has already been cleaned, so the hardest part of real work is missing. And a reviewer has seen the same notebook many times, so it tells them little about how you work.

Where good projects come from

Four places tend to produce projects people finish.

Something that annoys you. A task you repeat every month, or a question you keep looking up. Sorting your bank transactions into categories, finding duplicate photos in a library of 20,000, searching your own notes or PDFs by meaning instead of exact words, or predicting which of your GitHub issues will go stale.

A problem someone close to you has. A parent who keeps a shoebox of paper receipts for taxes, a friend who runs a small shop and guesses how much stock to order each week, a relative whose garden photos could show which plants look sick. These come with a real user who will tell you whether the result helps.

Something you find fun. Predicting results in your fantasy league, recommending songs from your own listening history, classifying clips from your running or climbing videos. Interest is what carries a project through the week where nothing works.

Something you're curious about. Does your sleep data predict how productive your next day is? Can a model tell your handwriting from your sibling's? When you want the real answer, you check the result more carefully than you would for a homework dataset.

The data from these projects is messy the way real data is: missing fields, inconsistent formats, duplicates, and labels you have to make yourself. Working through that is a large part of what the job looks like, and it is the part a cleaned-up benchmark skips.

Four sources of project ideas, each with two example projects: something that annoys you, a problem someone close to you has, something you find fun, and something you are curious about

Questions to ask before you start

A few questions are often worth answering before you commit to an idea.

Can you get the data, and quickly? If collecting or labelling the data takes months, the project usually dies before the first model trains. Aim for something you can start working with within a week: an export, a public API, a folder you already have, or a few hundred examples you can label by hand in an evening.
Do you know how to start? If the first step needs three tools you have never touched, the idea is probably too advanced for now. A project a little past what you can already build usually teaches the most. One that needs a research lab's compute, or a technique you can't yet follow when you read about it, usually stalls.
Is there a simple way to solve it without a model? If you can't think of one, such as a rule, an average, or the most common answer, you will have nothing to compare the model against.
Can you tell whether it worked? You need labels, a measurable outcome, or a person who can judge the output. "It looks good" is not a result.
Can you finish a first version in a couple of weekends? A small version that works can grow. A large one that never runs has nothing to show.
Is the data yours to use? Other people's messages, photos, or financial records need their permission, and private data should stay out of a public repository.

What a project needs to be worth showing

Whatever the topic, a few pieces separate a project from a notebook.

A baseline

A baseline is the simplest reasonable way to solve the problem: predict the most common category, use last week's number as this week's forecast, or match keywords. It is the number your model has to beat. Without it, 87% accuracy tells a reader very little, because guessing the most common category might already score 85%.

More than one dataset

If your claim is about a model or a method, test it on more than one dataset, ideally three. A method that wins on one dataset might be fitting that dataset's quirks. Three datasets with the same kind of problem, for example three people's transaction histories, or three public text classification sets, show whether the result holds up.

More than one model

If the project compares methods, compare three or more models, with the baseline as one of them. For a text classifier that could be keyword rules, logistic regression on word counts, and a small pretrained transformer fine-tuned on your labels. The comparison is the result, because it shows what each step up in complexity bought.

More than one way to evaluate

Use at least two evaluation methods, because a single accuracy number hides where the model fails. Pair accuracy with a metric that fits the problem. When some categories are rare, report precision (of the items the model put in a category, how many belong there) and recall (of the items that belong in a category, how many the model found) for each category. For a forecast, report the error in units people care about, such as items of stock or euros. Then read through the examples the model gets wrong. When a person uses the output, their judgement on 20 or 30 cases counts as an evaluation too.

All of these numbers come from a held-out set: examples the model never saw during training. Keep two held-out slices: a validation set for choosing model settings, and a test set you score once, at the end.

A short write-up

A README that says who had the problem, what data you used, what the baseline scored, what each model scored on each dataset, and what still fails. A results grid, with one row per model including the baseline and one column per dataset, is often the part of the repository a reviewer reads first. What a reviewer looks for beyond the grid, and five larger projects worth building once you have finished a first one, are in what ML projects actually get you hired.

A results grid with rows for a keyword-rules baseline, logistic regression, a small neural network, and a fine-tuned transformer, and columns for three datasets, showing accuracy for each

A worked example: a transaction tagger

Here is one of the ideas above planned with all of these pieces in place.

Problem: sorting a month of bank transactions into 10 categories by hand takes an evening, every month.
Data: your own export, a family member's export (with their permission), and a public transaction dataset from Kaggle.
Baseline: keyword rules from a list of merchant names you write by hand.
Models: logistic regression on the words in each transaction description, a small neural network on the same features, and a small pretrained text model fine-tuned on your labels.
Evaluation: accuracy on held-out months, precision and recall per category, and a read-through of the 20 transactions each model gets most wrong.
First version: label 300 transactions in an evening, run the baseline and logistic regression in one weekend, then add the other two models.

Where to see what others build

Kaggle competitions show many approaches to the same problem, often with notebooks and write-ups from people who placed well. Hugging Face has models and datasets to start from, and Spaces, small demos that other people built and published. r/learnmachinelearning and r/MachineLearning have project posts where the comments often point out what is missing. Looking through these gives a sense of how large a finished project is and how people present their results.

Common mistakes

Picking an idea because it sounds impressive, then dropping it at the first hard data problem.
Skipping the baseline, so the final number can't be read.
Tuning model settings on the test set, which makes the test score look better than the model is.
Testing one model on one dataset with one metric, then writing a general claim.
Publishing private data. Publish the code, a small fake sample in the same format, and the results.
Waiting until it is polished to share it. A first version with a clear list of what still fails is worth putting on GitHub.

QuiddityML ends each unit with a Projects section of small projects built on that unit's skills, each asking for something you can show, such as code, metrics, or a short write-up, which makes a good first version before the project becomes your own.