Blog / Career

How Many Projects Should You Include in Your Portfolio?

Recruiters spend less than a minute on a first pass. The number of projects you show matters less than the story each one tells. Here is a practical framework for deciding what to keep, what to cut, and how to present the work that counts.

1. The short answer

Show three to five projects. That is enough to demonstrate range, depth, and consistency without overwhelming the reader. If you are early in your career, three strong projects are better than five thin ones. If you are senior, five carefully chosen projects can show breadth across different domains, scales, and responsibilities.

The rule is simple: every project must earn its place. If a project does not show a different skill, a bigger impact, or a harder problem than the others, leave it out or fold it into a larger case study.

2. What recruiters actually look for

Recruiters and hiring managers are not trying to count your repos. They want to answer three questions quickly:

• Can this person ship? They look for live links, deployed services, published apps, or real-world outcomes.
• Can they solve real problems? They want to see problem statements, constraints, and decisions — not just features.
• Do they fit the role? They match your stack, domain, and seniority to the open position.

A small number of detailed, well-written projects answers these questions far better than a long list of screenshots.

3. How to choose your projects

Think of your portfolio as a curated exhibition, not a backlog. Use this filter to decide what makes the cut:

• Impact over effort. A small feature that saved a team ten hours a week beats a large unfinished prototype.
• Recency matters. Prioritize work from the last two to three years. Older projects can stay if they are still relevant and impressive.
• Diversify the evidence. Choose projects that show different muscles: one frontend-heavy, one backend/API, one ML or data system, one leadership or architecture example.
• Prefer production or production-like. Deployed work, live demos, and real user feedback carry more weight than local-only tutorials.
• Own your role. Be clear about what you built vs. what the team built. Honesty builds credibility.

4. What to include in each project

Each project page should follow a repeatable structure. The reader should know the context, the work, and the result within 30 seconds.

1. One-line outcome. Start with the result: "Built a real-time fraud-detection service that reduced false positives by 22%."
2. Problem and context. What was broken, slow, or missing? Who felt the pain?
3. Your role. Were you the architect, the lead, the sole developer, or a contributor?
4. Approach and trade-offs. What did you consider and why did you choose the path you took?
5. Tech stack. List the core technologies and why they fit.
6. Results and metrics. Quantify whenever possible: latency, throughput, adoption, revenue, or time saved.
7. Links. Live demo, GitHub repo, documentation, or a short video walkthrough.

5. Common mistakes to avoid

• Too many projects. A long grid forces the reader to do the filtering. Curate for them.
• Generic descriptions. "Built a React app" does not tell anyone what problem you solved.
• Missing outcomes. Without metrics, every project sounds like a homework assignment.
• Tutorial clones without a twist. If you include a To-Do app or a weather app, explain what you changed, extended, or learned beyond the tutorial.
• Broken links. A dead demo link is a red flag. Deploy and test regularly.

6. Final checklist

Before you publish, run through this list:

• You have 3–5 projects, each with a clear outcome.
• Every project links to a live demo, repo, or write-up.
• At least one project shows a measurable business or technical result.
• Your role is explicit in every project.
• Each page is readable in under two minutes.
• All images, links, and code snippets are current.

Want to see this framework applied? Browse the selected works or get in touch.