How you describe a project you built with a team, without overclaiming your part or shrinking it down to nothing, comes down to keeping two pronouns doing two different jobs in the same entry: "we" for what the team delivered together, and "I" for the specific piece of that delivery you personally owned. A bullet that uses only "I" for work several people actually did reads as overclaiming the moment a follow-up question probes it, and a bullet that uses only "we" throughout tells a reader nothing about what you, specifically, contributed, which defeats the purpose of listing the project at all.
Why a shared project still needs your own name in it
A hiring manager reading a CV entry about a team project is trying to answer one question: what would this person actually do if I hired them onto my team? A project description that only states what the team accomplished together answers a different question, what the team was capable of as a group, and leaves the reader to guess which parts of that group effort you personally handled. That gap is exactly what a specific contribution line fills. It does not need to claim credit for the whole outcome, and it should not; it needs to state, in one clause, the piece of the shared result that was actually yours to build, decide or fix.
Splitting "we" and "I" inside one entry
The cleanest way to hold both truths in one entry is to let each pronoun do a distinct job rather than picking one for the whole bullet. A first sentence describing the project and its outcome can use "we" honestly, since the outcome was genuinely a team result. A second sentence, or the second half of the same one, then narrows to "I" for the part that was actually yours: the component you built, the decision you made, the bug you tracked down, the piece of the system nobody else on the team touched. Readers do not expect a team-project entry to describe only your work in isolation from the group; they expect it to make clear where the group's work ends and your own begins.
Naming your part precisely instead of vaguely
"Contributed to" is the phrase most likely to undersell a real, specific contribution, because it describes almost any level of involvement equally poorly, from writing one function to leading the whole effort. Naming the actual piece, the service you owned, the integration you built, the migration you ran, the review process you set up, gives a reader something concrete to evaluate instead of a phrase that could mean anything. This is the same shift quantifying engineering impact on a CV without inventing numbers covers for turning a vague scope claim into a specific, honest one: precision reads as more credible than a rounder-sounding but vaguer description, not less.
Crediting the team without giving away your own line
Naming a shared result honestly does not require staying silent about your own part in it, and it does not require inflating that part either. A project entry can state plainly that a team of a given size built the thing together, then follow with the one or two sentences that are specifically about you, without either sentence undermining the other. The team-first sentence is not being generous at your expense; it is establishing the scale and context the reader needs to correctly weight the personal sentence that follows it. A reader who does not know a project involved five engineers over six months will read a single-person contribution to it very differently than a reader who does.
Illustrative example: a team-project bullet naming one person's part
Illustrative example, vague to specific. Vague: "Worked on a team that built a new checkout flow." Specific: "Part of a four-person team that rebuilt the checkout flow over one quarter; owned the payment-retry logic, the piece of the flow that handled a failed charge without losing the customer's cart." The second version credits the team's size and timeframe honestly, then states one specific, ownable piece of the shared result, so a reader comes away knowing both what the team built and what this particular person actually did inside it.
A few phrasings worth avoiding
A bullet written entirely in the passive voice, "the checkout flow was rebuilt," hides both the team and the individual behind a sentence with no subject at all, which reads as evasive rather than modest. A bullet that lists the whole team's output as a single unbroken list of "I" statements reads as overclaiming the moment a reader who knows the project, an interviewer familiar with the company, or a reference check, looks closer. Between the two, naming the team honestly and then naming your own piece specifically is both the more accurate description and, in practice, the one that survives scrutiny best.
Where a team project fits on your CV
A team project usually sits alongside individual projects in the same section, whether that is a dedicated projects area or, for a project built during a role, attached to the job entry it grew out of. The developer template prints project entries with room for both a short team-scope line and the specific-contribution sentence underneath it, which fits this two-part structure without forcing either half into a single cramped line. The same layout works whether the team project is the centrepiece of a bullet or a smaller addition alongside individual work like the kind covered in presenting side projects on a software engineer CV.
Add it to your CV
A team project, described honestly, is some of the strongest evidence a CV can carry, since it shows you can work inside a group and still account for your own piece of it clearly. Start from a template built for this kind of entry and add yours in the builder.