A lot of early portfolios end up looking similar: a to-do list app, a weather app, a clone of a well-known site, each built by following a tutorial step by step. None of that is wasted effort as practice, but as a portfolio, it doesn't tell a reviewer much — they've likely seen the exact same project dozens of times, built the same way.
What tends to stand out instead is a smaller number of projects, each with a clear answer to a simple question: why does this project exist, and what did you actually decide?
- Solve something specific, ideally your own problem. A small tool that scratches a real itch — tracking something you actually care about, automating a task you were doing by hand — comes with a story a tutorial project doesn't have.
- Make the decisions visible. A short write-up alongside the project explaining what you chose, what trade-off you made, and what you'd do differently next time shows more judgment than the code alone can.
- Finish it, including the boring parts. Error states, a basic design pass, a short README explaining how to run it — these are unglamorous, but their absence is one of the fastest ways a project reads as unfinished.
- Fewer, deeper projects beat many shallow ones. Two or three projects you can talk about in real depth, including what went wrong, are worth more than ten you can only describe in one sentence.
A portfolio isn't a list of technologies you've touched — it's evidence of how you think through a problem. Optimizing for that, rather than for volume, is usually the better use of your time.