The way to fit years of engineering work onto one page is not to shrink every project down to an unreadable fragment. It is to choose the three or four projects that best support the role you are applying for, group the rest into a single line near the bottom, and write each surviving project as one tight line rather than a paragraph. A page that tries to hold twelve projects at equal weight ends up holding none of them well; a page that holds four at full weight, with the rest acknowledged in passing, reads as a stronger CV even though it technically says less.
Deciding which projects earn a place
Start by ranking projects against the specific role, not against how proud you are of each one. A project that used the same stack the target role uses, solved a similar kind of problem, or shows ownership of a whole system rather than one small piece of it, earns a place ahead of a project that is technically impressive but sits far from what the role actually needs. Recency matters too, though less than relevance: an older project that maps closely onto the target role commonly beats a recent one that does not. Three or four projects is usually enough for one page once experience entries are also present; a CV that is mostly projects, with little paid experience yet, can stretch to five or six before the page starts to feel crowded.
A common mistake is ranking by effort instead of relevance: a project that took six months of weekends can feel like it deserves the top slot simply because of the time invested, even when a smaller two-week project maps far more directly onto what the target role actually does day to day. Effort is invisible to a reader who only sees the finished line on the page, so it is worth deliberately setting it aside and re-ranking by fit alone before finalising which four make the cut.
Grouping the smaller ones into a single line
Every project that does not make the top few does not have to disappear. A single line near the bottom of the projects section, something like "Also built: a Slack notification bot, a small CLI for log searching, and two internal tooling scripts", keeps them visible without giving them the same real estate as the featured entries. This line does real work: it signals that the featured projects were chosen deliberately rather than being the only things you have ever built, and it gives a reader who wants more a starting point to ask about in a conversation, without forcing every project through the same full write-up.
Writing a one-line project entry
A one-line project entry still needs to answer what it is, what it was built with, and what came of it, just compressed into a single line instead of three. "Metrics dashboard - React and a small Node API pulling from an internal event stream, replaced three separate spreadsheets the team had been using to track the same numbers manually" fits comfortably on one line and still tells a reader something concrete. Cutting a project down to a bare title with no context, on the other hand, saves space without keeping any of the information that made the line worth including in the first place. The goal is density, not brevity for its own sake: a line that says less in fewer words is not automatically a better line.
Illustrative example: a trimmed project list
Illustrative example. A candidate has nine side and work-adjacent projects built over several years. Before trimming, each one gets its own two-line entry, and the projects section alone runs to most of a page on its own. After trimming: four projects are kept at full detail, chosen because they most closely match the target role's stack and scope, each written as one line with what it is, what it used and what changed because of it. The remaining five are folded into a single closing line naming each one briefly. The projects section now takes up roughly a third of the space it did before, and the four featured entries are easier to read carefully because they are no longer competing with five others for the same attention.
Keeping the page readable while you compress
Fitting more onto one page by shrinking font size or margins past a comfortable reading size trades one problem for a worse one: a page that technically holds everything but is uncomfortable to read loses more than a page that honestly needed a slightly longer format. Compression should come from choosing what to include, not from making the text itself harder to read. If four full project entries and a grouped line still will not fit at a normal reading size, that is usually a sign to cut a fifth project rather than to shrink the text further, or a sign that this particular CV can honestly justify a second page.
When projects and experience are competing for the same page
For an engineer with several years of paid experience and a long list of side projects, both sections are competing for the same limited space, and experience should usually win that contest first. A reader evaluating a mid-career engineer generally weighs paid, accountable work more heavily than a side project, so trimming the projects section down to its featured few, rather than trimming experience entries to make room for more projects, is usually the safer place to find the extra space a one-page CV needs.
Build yours
Pick a template built for engineering work, such as the Developer template, and work through your own project list with the same filter: which few projects most directly support the role, and which can be named in a single closing line instead. For the general question of how long a CV should run before projects even enter the picture, how long should a resume be covers the wider tradeoffs, and presenting side projects on a software engineer CV covers how to write a single project entry in more depth once you know which ones made the cut. Start trimming and rebuilding at the builder.