How to Choose Projects That Prove Real Skill

Why most portfolio projects say nothing

Follow a popular tutorial and you will end up with the same chatbot, the same recipe generator, the same summariser that a great many other people also finished this month. The build might have taught you something. As evidence, it is close to worthless, because the reader cannot tell where the tutorial ended and you began.

The problem is not quality. Some of those tutorial projects look polished. The problem is that they answer a question nobody asked, using a dataset nobody cares about, with every hard decision already made for you by the person who wrote the instructions.

A project becomes evidence when a stranger reading it can tell that you were the one steering.

The four things that make a project evidential

A real problem. Something that was actually annoying somebody, ideally you. Not a hypothetical use case. If you cannot name the person who was losing time, it is not a real problem.

Real constraints. The data was messy. There was no budget for a paid tool. Certain information could not leave the building. Constraints are the interesting part, because working inside them is what the job is.

A decision you had to make. A fork in the road with two defensible options where you picked one and can say why. This is the single strongest thing you can show, and tutorials strip it out entirely.

A result you can describe. Not necessarily a win. A clear before and after, in plain numbers or plain words, including the parts that stayed manual.

Your existing career is the raw material

This is the part most people miss. You are not starting from zero. You are starting with something most people building AI demos do not have, which is a detailed understanding of how some real job actually works.

A teacher knows exactly which part of marking is mechanical and which part requires judgement. A nurse knows what a handover note has to contain and what happens when it is wrong. An accountant knows why a categorised transaction can be technically right and still misleading. A shop manager knows why the rota is hard, and it is not the arithmetic.

That knowledge is why your project can be better than a generic demo. You will pick a problem worth solving, you will notice when the output is subtly wrong, and you will be able to answer follow-up questions because you have lived the thing.

Finding your candidates

Do not sit and wait for a good idea. Go looking in your own history, systematically.

I want to find portfolio project ideas inside my own work history rather than generic ones.
Ask me one question at a time, up to ten questions, about the jobs I have done. Focus on tasks that were repetitive, tasks where information had to be reformatted or moved between places, and tasks where people made avoidable mistakes.
After the questions, give me five candidate projects. For each, state the problem in one sentence, who was losing time, and what would make it hard to do well.
Start with your first question.

Then pressure test the shortlist before you commit a single evening to it.

Here is a project idea I am considering for a portfolio.
Judge it as evidence, not as a product. Answer:

Could someone build this by following a tutorial without understanding it? If so, it is weak.
What decision would I have to make that a tutorial would have made for me?
What real-world messiness would this have to survive?
What is the smallest honest version I could finish in about ten hours?
If the idea fails on point one, say so directly and suggest how to change it.
[describe your idea]

If two ideas survive, choose the one you can explain to a stranger fastest.

Here are two project ideas I am torn between.
For each one, write the single sentence I would say if someone asked what I built. Then tell me which sentence a person outside my industry would understand without a follow-up question, and why.
Recommend one. Give the reason in two lines, then stop.
IDEA A: [describe]
IDEA B: [describe]

A note on other people's data

If the problem comes from a workplace, the data usually cannot come with it. Never put real names, records or client information into an AI tool without permission, and never publish it. Rebuild the problem with invented sample data that has the same shape and the same messiness. Say in your write up that you did this. Nobody will hold it against you, and handling that boundary carefully is itself a thing employers notice.

Next: how to actually build the thing without disappearing into it for six months.