“What should be in my portfolio?” Almost every developer fresh out of a course asks this. The answer is simpler than you'd expect: little, but real.
A hiring manager has little time. They look at a few projects and decide quickly. They don't need ten similar course projects; they need some proof: that you understand the problem, can build it and can see the work through.
Why proof, not numbers
On a course everyone does the same assignments: a task list, a weather forecast, a calculator. They're great for learning, but in a portfolio they don't set you apart. The hiring manager has seen hundreds of them. They're looking for what you did differently.
That's why three projects in a portfolio are enough — but each one should prove something different.
1. A real problem for real users
It can be small: an order form for a relative's shop, a queue system for a school, a sign-up for a sports club. What matters is that real people use it.
This project shows that you don't just write code: you understand the problem, talk to the user and get a result. In the description, write who used it and what changed.
2. A project that shows depth in your stack
This project should show deep knowledge, not surface: tests, user login and roles, error handling, performance, deployment to a server.
- If you're a Laravel developer: queues, caching, tests, a well-designed database.
- If you're a Flutter developer: state management, offline mode, a store release.
A tech lead looking at this project should see that you know the difference between “it works” and “it works right”.
3. Teamwork or open source
Nobody works alone in a real job. A project built with a team — a hackathon, a volunteer project or a contribution to an open-source project — shows that you can read other people's code, work with Git, go through review and reach agreement.
Hackathons are a great opportunity for this: a team, a real task and mentor feedback in a short time.
How to present each project
The presentation matters as much as the project itself. For each project:
- One sentence: which problem it solves.
- A live link or a short video. Nobody wants to set up your project on their own computer.
- Screenshots.
- Your role. If it's a team project, what exactly you did.
- Technical decisions and the reasons for them. “I chose this because…”
- What you learned and what you'd do differently now. That's a sign of maturity.
GitHub habits
- A clear README in every repository: what it is, how to run it, a screenshot.
- Meaningful commit messages: not “fix”, but “fixed the empty phone number error in the order form”.
- Passwords, secret keys and the .env file should never end up in the repository. A hiring manager who sees that won't give you access to a server.
- Pin your three best projects on your profile.
What not to show
- An unchanged copy of a course project.
- Half-finished repositories with two commits.
- Broken links. There's no worse first impression.
Talking about a project in an interview
Tell the story of the project, not a list of technologies: what the situation was, what the problem was, what decision you made and what came of it. The strongest sentence is: “I made this decision because…” It shows that you think — and in the age of AI, that's the most valuable skill. I wrote about this in more detail in “AI writes the code. So what does a developer do?”.
If you're thinking about freelancing, start with “Starting freelance”. And if your portfolio needs an outside eye, let's go through it together in mentorship: what to keep, what to drop, what to add.
