How many projects should a developer put on a resume?

There is no single correct number, but there is a pattern: the less professional experience you have, the more the Projects section needs to carry, and the more experience you have, the more that same space gets crowded out by real work history. Here is how the right number actually shifts by stage.

No professional experience: three to four projects

With nothing in Work Experience, Projects is effectively the main body of the resume, so it needs enough entries to demonstrate range without padding. Three or four well-chosen, well-documented projects, each proving something different (a UI problem, a backend/data problem, a completed end-to-end app), covers more ground than a long list of thin ones. See the full structure for this case in how to write a developer resume with no experience.

Resist the urge to list every coursework assignment. A reviewer skims a resume in seconds; ten mediocre entries dilute the two or three that are actually strong.

Junior, one to three years of experience: two to three projects

Once you have real work experience, Projects shifts from “main evidence” to “supplementary evidence,” specifically for things your job did not give you a chance to show. If your day job is backend-heavy, a personal frontend project demonstrating range is worth including. If your job already covers the full stack you want to be hired for, the Projects section can shrink further, or even drop entirely, in favor of more space for Experience bullets. Two or three strong entries is typically enough here.

Experienced, three-plus years: zero to two projects, and only if they add something new

At this stage, the strongest signal on the resume is almost always Experience: real systems, at real scale, with real constraints. Projects still earn a spot when they show something the job history genuinely does not, deep expertise in a technology you want to pivot toward, a substantial open-source maintainer role, or a side project with real, measurable adoption. A project that just restates skills already obvious from your job history adds nothing and costs space that could go toward a stronger Experience bullet instead.

The test that applies at every stage

Before including a project, ask what it proves that nothing else on the resume already proves. If the honest answer is “not much, it’s just another example of a skill I’ve already demonstrated,” it likely does not belong, regardless of how much effort went into building it. This is the same filtering logic covered in more depth in how to choose which GitHub projects belong on your resume.

Quality compounds; quantity does not

A resume with three deeply described, genuinely distinct projects consistently reads stronger than one with seven briefly described, similar ones. This holds at every experience level. If you are unsure whether to include a fourth or fifth project, the better use of that space is almost always a longer, more specific description of the strongest three, not another shallow entry. See how to describe GitHub projects on a resume for what that added specificity should actually look like.

Letting real activity set the number

resumefromgit.com reads a public GitHub profile and surfaces repositories ranked by real signals, stars, recent activity, documentation, rather than requiring a manual audit of everything you have ever pushed, which makes it easier to see at a glance whether you genuinely have three strong candidates or are stretching to fill a number.