How many projects belong in a portfolio

Ask ten people how many projects a portfolio should have and you'll get ten numbers between three and twelve, most of them delivered with total confidence and none of them backed by a reason beyond "that felt right." The number itself is the wrong thing to be confident about. What's actually knowable is how a reviewer aggregates what they see, and once you understand that mechanism, the count stops being a guess and becomes an output of a different, more useful question: does this project raise or lower the average, and can you tell before you publish it.

Here's the mechanism. A reviewer looking at a portfolio with six projects does not form a judgment by finding your best one and ignoring the rest, and they don't form it by summing everything either. What actually happens is closer to an average pulled down hard by the worst entry — because the worst project reads as a data point about your floor, not an outlier you get to explain away. A reviewer who sees one excellent case study and four merely competent ones doesn't conclude "this person has one excellent gear." They conclude "this person's typical output is competent, and once, they got lucky or had help." The strong project gets discounted toward the average instead of the average getting pulled up toward it. That asymmetry is the entire argument for cutting rather than adding, and it's the opposite of how most people build these pages — they add a project because it can only help, on the unexamined assumption that a portfolio is scored by its maximum. It isn't. It's scored closer to its average, and every project below your current standard drags that average down, including the ones that felt too good to leave out.

This has a direct implication for format that most portfolio advice skips: if you're publishing as a single scrolling page rather than a multi-project site with a grid, the question of how many projects fit isn't just editorial, it's structural. reach generates exactly that kind of page — upload a CV and a photo, and a finished one-page site is generated in about twenty seconds, live at a free yourname.joinreach.app subdomain in under two minutes. Its "own projects" section holds a small number of entries shown well, not an open-ended gallery, which matches the argument above rather than fighting it: a page that physically can't hold twelve mediocre projects can't tempt you into the average-lowering mistake. The real limitation worth naming is that reach makes one page only — no second page for an archive, no site tree to hang overflow work on — so anything you cut has to live somewhere else if you want to keep it available at all. For a portfolio disciplined enough to want three or four projects and nothing more, that's not a cost. For anyone who wants a tight front page and a browsable archive on the same site, it's a real one.

Rank your projects with no ties allowed

The exercise that actually produces a defensible number is not "which projects am I proud of" — everyone answers that the same unhelpful way, which is all of them. It's a forced ranking: list every project you could plausibly include, then put them in strict order from strongest to weakest with no ties permitted. Not "these two are basically equal." Pick one.

The reason ties aren't allowed is that the ranking is doing real work, not just organizing your thinking. Once every project has a distinct rank, you draw a line, and everything below it doesn't make the page — not because it's bad, but because it's worse than what's above it, and a portfolio built on relative strength gives you a much clearer editing rule than "is this good enough," which almost everything you've shipped will pass. "Is this better than my third-best project" is a harder question and a more useful one, because it's the question a reviewer is implicitly asking too, just faster and less generously.

Where to draw the line depends on depth, not a target number. A project shown with real reasoning — the brief, what you tried, what didn't work, what you'd change now — takes up more of a reviewer's ninety seconds than a project shown as a screenshot and a caption. If you can only write three projects to that standard in the time you actually have, three is your number, and a fourth project shown thinly doesn't add breadth, it adds a visibly weaker entry next to three strong ones, which is worse than not including it.

The eight-month project is not owed a place

The hardest cut is usually not the weak project everyone can see is weak. It's the project that took the longest, cost the most, or mattered most to you personally at the time, and the instinct to keep it isn't really about its quality — it's sunk cost dressed up as significance. You spent eight months on it, so it must be the centerpiece. That reasoning has nothing to do with what a reviewer will get from looking at it, and it's worth naming directly because it's the single most common reason people keep a project that's actively working against them.

Effort and evidentiary value are not the same axis. Some of the most persuasive case studies come from small, fast projects where the constraint was tight and the reasoning is easy to follow in three paragraphs. Some of the least persuasive come from long projects where the decisions got diluted across months of incremental changes, committee input, and scope drift, so that by the end nobody — including you — can point to a single choice and say "that one was mine and here's why I made it." Ask the ranking question honestly: not "how much did this cost me," but "how clearly can I show a decision here." If the eight-month project scores low on the second question, it goes below the line regardless of what it cost, and keeping it in the top slots because it feels wasteful not to is exactly the average-lowering mistake from the first section, with a more sympathetic excuse attached.

Range without weakness

The usual defense of a longer portfolio is range — proof that you can do more than one kind of work, which matters in fields where a role genuinely spans several skill sets. That's a real need, but it doesn't require more projects at full depth. It requires variety within the projects you already ranked highly.

If your top three projects demonstrate the same skill from three angles, that's a weaker signal than if they demonstrate three different skills once each, even holding overall quality constant, because a reviewer staffing a role that needs range gets more information from breadth among your strongest work than from depth in one lane plus weaker additions elsewhere. So when choosing which strong projects make the cut, weight for what each one proves that the others don't, not just for how good it is alone. That gets you range for free, inside the count you'd already committed to, instead of range purchased with weaker material.

Keep the rest, just not on the main page

None of this is an argument for deleting work. Cutting from the front page and destroying the work are different decisions, and conflating them is why people resist cutting in the first place — it feels like erasing something real. The fix most working portfolios land on is a separate archive: a page, linked from the main site but not competing with it for attention, where everything that didn't make the ranked list still lives, in whatever form is convenient, for the smaller number of visitors who specifically want more.

That split matters because the two audiences want different things. The ninety-second reviewer wants the ranked, argued version — three to five projects, each earning its place. A hiring manager doing final diligence, or a peer curious how you work, sometimes wants the full record, and an archive serves that reader without forcing the first one through it. For the structure that holds up under a ranked, primary read, see portfolio examples worth copying; for writing up a single project well enough to survive the cut, see how to write a case study.

Where more is actually right

All of this argues for fewer projects because it's written from the position most readers are in: one person, applying for one role, being evaluated on judgment. That's not every situation. Agencies reviewing a portfolio for a production-heavy role — someone who'll turn around a high volume of client work at a consistent baseline rather than make a handful of high-stakes calls — are often evaluating range and throughput, not depth of reasoning on any single piece. A junior production designer's portfolio showing fifteen varied executions can be the right answer for that review, because the question being asked is "can this person handle volume across different briefs," not "can this person defend one hard decision under scrutiny."

The test isn't the number, in either direction — it's whether you know which question you're being asked. A judgment-based review punishes a long portfolio because it dilutes the average. A volume-based review can reward one, because volume is what's being measured. Most individual-contributor hiring, above entry level, is the first kind. If you're not certain which applies to the role in front of you, the portfolio that gets you hired covers how reviewers actually read a page in the more common case, and it's the better default when you don't have a specific signal saying otherwise.