How Many Projects Should I Have on My Resume?
Two, and at least one has to open in a browser. How to count your projects the way the person reading them counts, and how to know when to stop building.
By Howard Davner
Quick Answer: Two, and at least one of them has to open in a browser. The count that changes anything is not how many projects you have built, it is how many a reviewer can verify without contacting you. A single project at a live URL does more work than a longer list nobody can check.
You have built one project, maybe two, and instead of applying you are trying to work out whether you need a third. The question feels like it has a number for an answer, so the safest-feeling move is to keep building until the number arrives.
It does not arrive. Here is what to do instead.
How many projects should I have on my resume?
Two, with at least one of them deployed at a URL a stranger can open. The second only earns its slot if it proves something the first does not.
By where you are:
- No internship yet, applying for your first: Projects to list: 2 (1 deployed minimum); What decides it: The deployed one carries the application. The second shows range.
- Coursework only, nothing deployed: Projects to list: 1, after you deploy it; What decides it: Deploying what you have beats starting something new.
- Applying to two different kinds of role: Projects to list: 2, one per role type; What decides it: One project per bucket of jobs, not one project stretched over both.
- You already have an internship or relevant job: Projects to list: 0 to 1; What decides it: A project earns space only by showing what the job did not.
What does not earn a slot is a second project with the same skill, the same depth and a different dataset. That is the same proof twice, and a reader who spots it learns nothing from the second one.
Why every guide gives you a different number
Because the number is the wrong variable, and you can see the disagreement on the first page of results. The guides ranking for this question recommend two to four, or one per role, or however many are relevant, or decline to give a figure at all. They are not being careless. They are each answering with the part of the problem they can see.
The part they mostly leave out is verification. Nearly every one of them treats a repository link and a running application as interchangeable evidence, with a live demo listed as a nice extra. On the screen they are not close to interchangeable, and that single distinction reorders the whole answer.
The only count a reviewer can act on
Of everything on an entry-level resume, a working link is the one item the reader can confirm while they are holding it. Nothing else clears that bar.
- A GPA, a graduation date, a course list: they will take your word for it or check much later.
- A skills section: a list of nouns, unverifiable by design.
- A project name with a repository link: work they would have to do, in the one part of the process where nobody does extra work.
- A live URL: they click, and in a few seconds they know something is real and you built something that stays up.
So there are two counts running. There is the number of projects you have built, which is yours, and the number a reader can confirm in the moment, which is the one that changes the application. For most applicants the second number is zero, and adding a fourth project to the first number leaves it at zero. That is why "build more projects" so often produces no change at all. It moves a number nobody is reading.
This is also why a repository on its own carries so little on the screen, even when the code is genuinely good, and why the deployed version is the thing worth putting on the resume line.
Where the projects go on your resume
Give them their own section, titled Projects, placed below Experience by default. Move it above Experience when the projects are the stronger evidence, which is usually true if your work history is retail, food service or campus jobs unrelated to the role.
Two placement mistakes worth avoiding:
- Scattering projects through Experience. A reader scanning for employers reads each entry as a job, then works out it was not one. That is a small act of misdirection and it costs you the goodwill of the person doing it.
- Burying the link. If the URL is only in your GitHub profile or at the bottom of a portfolio page, it is two clicks away, and two clicks is past where the screen ends. Put it in the project entry itself.
What one project entry should contain
Three parts, in this order: what it does, what you decided, and where it runs.
- What it does, in one line, for someone outside your degree. "Flags duplicate maintenance tickets before a technician is dispatched" tells a reader more than "full-stack ticketing application using React and Postgres."
- One decision you made and why. Not the tool list. The tradeoff. Why you cached instead of querying live, why you capped the upload size, what you deliberately left out. This is the part nobody can copy from you, and the part an interviewer will open with.
- The live URL. Plain text, not hidden behind a word, so it survives being pasted into a plain-text application form.
A group project follows the same shape, with one addition: name your own piece inside it. Shared credit is normal. Vagueness about which part was yours is what reads badly.
When to stop building and start applying
Stop when you can send the link and answer three questions cold: what problem it solves, why you built it that way, and what you would change. If you can, project three will not change your application. If you cannot, the gap is inside the project you already have, and a new project inherits it.
The honest version of the stall is that building is comfortable and applying is not, and "my portfolio is too thin" is the most reasonable-sounding way to stay in the comfortable half. The fix is rarely another project. It is usually getting one existing project deployed, then written up so the link and the reasoning arrive together, which is the same problem as working out what a reviewer is actually looking for in a portfolio.
If the blocker is that nothing you have built is live yet, that is the step worth taking first. Provieo's project builder takes a job description, works out a project that fits it, and gets it deployed at a URL you can put on the resume. It is free to use, the first build and deploy costs nothing, and after that it is a single one time payment for unlimited deployed projects rather than a recurring charge.
The number of projects on your resume was never the thing holding up your application. The number a stranger can open usually is.
Frequently Asked Questions
How many projects should I have on my resume?+
Two, and at least one of them should open in a browser at a live URL. The second earns its place only if it shows something the first does not, such as a different skill, a different kind of problem, or work done inside a team rather than alone. A third is almost always the same proof point again. If you have one deployed project you can explain decision by decision, you have enough to start applying.
Is one project enough for a resume?+
Yes, if a stranger can open it. One project at a working URL, solving a problem someone would recognise, with decisions you can account for, is stronger than a list of repository names. One openable project is a thing the reader can confirm in the moment. Four unopenable ones are four claims they have to take on trust, and the screen is the worst place to be asking for trust.
How many projects should I list if I already have an internship or work experience?+
One, or none. Projects exist on an early-career resume to stand in for work history you do not have yet. Once you have the history, a project only earns space by showing something the job did not, such as a stack the role never touched or a system you owned end to end. Otherwise the space is better spent on what you shipped at work.
Where do projects go on a resume?+
In their own section called Projects, below Experience in most cases. Move it above Experience when the projects are the stronger evidence, which is common if your work history is retail, hospitality or unrelated campus jobs. Do not scatter projects through the Experience section, because a reader scanning for employers will read them as jobs and then notice they are not.
Do class or coursework projects count as resume projects?+
Yes, as long as you made a decision the assignment did not make for you. A submission built to a specification proves you can follow one. The same project becomes evidence once you extend it past the brief, deploy it, or change something and can say why. Label it honestly as coursework. Nobody minds where it started; they mind whether you drove any of it.
Does a GitHub link count as one of my projects?+
It counts in the interview and thinly on the screen. A repository is code someone has to read or run before it tells them anything, and the first pass through an application pile has no room for that. Put the live URL on the resume and keep the repository link for the technical conversation, where someone will actually want to read the code.
How do I know when to stop building and start applying?+
Apply when you can send a link and answer three questions about it without preparing: what problem it solves, why you built it the way you did, and what you would change. If you can do that, another project will not improve your application. If you cannot, the gap is in the project you already have, and building a new one carries the same gap forward.
Put a working link in your next application.
Paste the job you're applying to. Provieo designs a project against that exact listing and walks you through deploying it, so what a recruiter clicks is the work itself, not a description of it.
Free to use, and your first deployed project is free. Or tailor your resume to the same posting.