A portfolio is not a gallery. It is an argument, and the argument is that hiring you is low risk. Most junior portfolios lose because they answer a question nobody asked: can you follow a tutorial. Everyone can.
Here is what to build instead, and how to present it so a busy reviewer reaches the same conclusion in ninety seconds.
The three projects, and what each proves
Project one: a full CRUD application with authentication
Users sign up, log in, and create, edit and delete their own data. Somebody else’s data must not be visible or editable.
This proves you can build the thing that eighty percent of commercial software is. It also forces you through the problems that matter: sessions, permissions, validation, and what happens when input is wrong.
A task manager is fine. A clinic appointment system is better, because it has real constraints.
Project two: something that consumes a real external service
A payment gateway, a mapping API, a weather service, a courier tracking API. The point is not the integration. The point is what you do when it fails.
Handle the timeout. Handle the rate limit. Handle the empty result. Show a useful message rather than a spinning circle forever. Reviewers specifically look for this, because production software is mostly failure handling and juniors almost never demonstrate it.
Project three: something a real person asked for
This is the one that gets the interview. A local shop that needs an order form. A family business that tracks stock in a notebook. A friend’s clinic that books appointments over WhatsApp.
It proves the thing no clone can: that you can take a vague human request, ask the right questions, decide what to build, and ship something that a person then used. That is the actual job.
It does not need to be big. A two hundred line tool that a shop genuinely uses beats a thousand hour clone of a product with a design team.
Why clone projects stopped working
A Netflix clone, a food delivery clone, a calculator, a weather app. There is nothing wrong with building these while learning. The problem is that every applicant has them, so they carry no information.
Worse, a clone tells the reviewer that the design decisions, the data model and the feature set were all made by somebody else. Everything you would be hired to do was already done.
Keep them on GitHub. Do not put them on the portfolio.
The README that does more than the code
Most reviewers do not read your code. They read the README and then open the live link. So the README is the highest leverage file in the repository.
A good one has:
- One sentence on what it does and who it is for.
- A live link at the top, not the bottom.
- One screenshot. Just one.
- The stack, in one line.
- What was hard. This is the section that gets you hired. Two paragraphs on the problem you hit and how you solved it demonstrates engineering better than any amount of code. It also becomes the first ten minutes of the interview, on ground you have already prepared.
- What you would do differently. Self assessment reads as maturity, not weakness.
Presentation rules
- Everything must be live. A project without a working URL does not exist for hiring purposes. Free hosting is sufficient.
- Test the link on a phone before you send it. Reviewers frequently open on mobile, and a broken layout ends the review.
- Seed the demo with data. An empty application looks broken. Fill it so a reviewer sees it working within five seconds of landing.
- Provide demo credentials directly on the login screen. Making someone register kills more reviews than any technical flaw.
- Three projects, not nine. A long list reads as an inability to judge what matters.
The portfolio site itself
You do not need one. A well organised GitHub profile with three pinned repositories and good READMEs is enough, and it is what most reviewers open anyway.
If you do build one, keep it to a single page: who you are in two lines, three projects with links, contact. Portfolio sites that are elaborate but list no working projects are a common and self defeating trap.
Commit history matters more than people think
A repository with one commit saying “final” tells a reviewer you developed locally for weeks and pushed once, or that the code came from somewhere else. Neither helps.
Commit as you work, write messages a colleague could read, and let the history show the project being built. It is free evidence and almost nobody uses it deliberately.
What to do if you have nothing yet
Pick project three first and go find the person. A shop, a tutor, a clinic, a small NGO. Offer to build one small thing free. You get requirements, feedback, a deadline and a real user, which is the entire content of the portfolio piece that matters.
If you would rather do that inside a structured programme with review and deadlines, that is what an internship is for. Ezitech’s hybrid internships place trainees on live client work, and our note on writing the CV around it covers how to present the result.
Frequently asked questions
How many projects should a junior developer have?
Three finished and deployed. Quality and completeness beat quantity, and a long list actively hurts.
Do employers really look at GitHub?
Yes, briefly. They check that it exists, that there is recent activity, and that the pinned repositories have READMEs and working links.
Should I put university projects on my portfolio?
Only if you can deploy them and explain every decision. Group projects where you built one screen are usually better left off.
Is a personal website necessary?
No. A good GitHub profile does the same job. Build the site only when you have projects worth linking from it.
Ezitech runs three month hybrid internships in web, mobile, data and design, built around shipping real client work. See the current programme.