Skip to content
Web Development28 September 2026 · 9 min read

How to Present Collaborative Work Honestly

A project can belong in your portfolio even when you did not build all of it. How to name your role, separate it from the collaborator build, and keep the boundary visible.

How to Present Collaborative Work Honestly

A project can belong in your portfolio even when you did not build the whole thing. The honest version names your role in a single line, separates what you owned from what already existed, and leaves the reader nothing to guess at. Most portfolio dishonesty is not invention but omission, and readers fill omissions in generously, in your favour, every time.

This is a writing problem more than an ethics problem. Nobody sits down intending to imply they built a site they only wrote for. It happens because the case-study format rewards a clean narrative, and a clean narrative has one protagonist. The fix is a small set of structural habits: a role line, a boundary paragraph, captions that name the contribution rather than the product, and a metrics rule you apply before you are tempted. One of the projects on my own portfolio is a collaboration where I wrote none of the code, and getting its labelling right took longer than the work it describes.

Deleting the project is the dishonest option

Removing collaborative work is less honest than showing it with precise role boundaries. A portfolio with the collaborations stripped out describes a freelancer who only ever works alone, which is a false picture of how almost anyone actually works. You have quietly traded one misrepresentation for another, and the one you kept is harder to spot.

There is a practical cost too. Collaborations are usually where the interesting constraints live. Working inside someone else's build, matching an existing content model, publishing into a CMS you did not architect — those are real skills, and they are exactly the skills a client hiring you for a slice of a larger project wants evidence of. Delete them and your portfolio only proves you can do greenfield work.

The nervousness behind deletion is understandable. A half-project feels like a weak project. It is not, provided the half is stated plainly and the half you did is genuinely yours. What makes a case study weak is ambiguity, not modesty.

What does an honest case study owe the reader?

An honest case study owes the reader four facts: who built what, what you owned, what already existed before you arrived, and which outcomes you cannot claim. Those four fit in a paragraph. They are also, near enough, what the professional bodies have required for years. The AIGA Standards of Professional Practice state at section 5.1 that a designer shall not claim sole credit for work others collaborated on, and that such work may not be used for portfolio samples without clear identification of the precise areas of authorship. That is a standard, not a suggestion.

Architecture is stricter still, and the wording is worth stealing. AIA Rule 4.201 requires members to accurately state the scope and nature of their responsibilities in connection with work for which they are claiming credit, and the guidance adds that the attribution must be no less prominent than the project description itself. Prominence is the part most portfolios fail. The credit exists, technically, in a grey line under the fold.

So the rule I write to is simple. If a reader skims the page and stops after the title, the tagline and the first screenshot, have they already been told what was mine? If not, the boundary is buried, and buried is the same as missing.

Rewrite the claim, not the project

You almost never need to remove a sentence. You need to make it specific enough that it cannot be read two ways. The pattern is always the same: replace a collective verb with a named one, and attach the deliverable.

What people writeHow a reviewer reads itWrite this instead
"We built a fitness content platform."You were on the build team. Probably engineering."Collaborator built the Webflow site; I wrote and published the article set through the CMS."
"Led content strategy and SEO."You owned the strategy and had people executing it."Drafted, edited and published the article set; keyword mapping was mine, the site architecture was not."
"Increased organic traffic 40%."You caused that number."Site traffic grew during the period I was publishing; I do not have attribution data isolating the content's effect."
"Redesigned the checkout flow."You designed it."Redesigned the payment step inside an existing checkout; cart and confirmation screens were unchanged."
"Role: Developer, Designer, Strategist."You did everything."Role: content. Build, design and hosting by [collaborator name]."

The right-hand column is longer in every row. That is the trade. Precision costs words, and a portfolio that refuses to spend them is choosing a vaguer reader impression on purpose.

Here is how that went on IronLife.

I did not build the IronLife Webflow site. Milan built the site; my role was drafting fitness and SEO articles with AI assistance, editing them and publishing them through the CMS. I keep the project in my portfolio because the content work was real, and I label the boundary because the Webflow build was not mine.

That labelling is not buried in the body copy. On the IronLife case study the category field reads "Content / CMS collab" rather than the usual "Website", the tagline names the collaborator's build before it names my contribution, and the page's own meta description says the site build was Milan's. A reader who sees nothing but the card in a grid still gets the boundary. Compare that with the Elpida Solutions build or the Šahovski klub Dubica site, where the category says "Real estate website" and "Community website" because those were mine end to end. The difference is visible before you click.

How do you caption screenshots and video?

Show the finished product, then caption your slice of it in the same breath, naming the contribution rather than describing the interface. Screenshots are where collaborative credit quietly collapses, because an image of a polished interface reads as authorship no matter what the paragraph above it said.

Two habits fix most of it. First, caption what the image demonstrates about your work rather than what it depicts: "article template populated through the CMS" beats "IronLife homepage". Second, if the shot is dominated by design you did not do, either crop to the region you touched or say so in the caption. A screen recording of a page you wrote the copy for is fine; a hero shot of a layout you never opened, captioned with nothing, is the ambiguity doing its work again.

Video is worse, because motion implies craft. If you are showing a scroll-through of a site you contributed content to, a two-second title card naming the build credit costs you nothing and removes the whole question.

Which numbers are you allowed to use?

You may use numbers you produced, numbers you measured yourself, and numbers you attribute to a named source in the same sentence. Everything else belongs to whoever earned it, and borrowing a result is the fastest way to lose a reader who checks.

Borrowed metrics are where an omission stops being sloppy and starts being a claim about your effect. The regulatory direction of travel is unambiguous on the adjacent question: the FTC's Rule on the Use of Consumer Reviews and Testimonials took effect on 21 October 2024 and targets, among other things, misrepresenting what actually happened when someone experienced a product or service. It governs reviews rather than portfolios. The reasoning generalises anyway, and at the end of 2025 the agency used the Rule publicly as an enforcement tool for the first time, sending warning letters to nearly a dozen companies with a five-business-day window to respond and penalty exposure of $53,088 per violation.

When you genuinely lack the data, say that. "I do not have analytics access for this period" is a stronger line than a number you cannot defend, because it tells the reader you know the difference between the two. Actually, let me back up slightly: it is stronger only if the rest of the case study is specific. Admitting one gap in a page full of vagueness just reads as more vagueness.

The red flags reviewers screen for first

They screen for teamwork framed as personal work, and they do it before they read your process. Tom Scott's May 2026 list of eight red flags in design portfolios puts "no clarity on what you did" among them, calling out vague "I led" language with no specific contribution named. The screening now happens at skim speed, not in the interview.

The three that come up most:

  • "We" with no team. A solo freelancer writing "we" is usually reaching for the credibility of a studio. It reads as a tell, and it makes every other pronoun in the page suspect.
  • Unnamed collaborators. "Built with a partner" tells a reader you either forgot who they were or would rather they were not findable. Name them, or state the constraint that stops you naming them. Either is fine. The blank is not, because a reviewer who cannot verify a collaborator has to decide whether to believe the whole page on your word alone, and most will simply move on.
  • Scope drifting up the page. A role line that says "content" under a title that says "platform build". The title is what gets remembered.

You have skimmed a portfolio like this. Page loads, screenshots look good, and somewhere around the third project you start wondering what this person actually did. That wondering is the failure.

When you cannot name the collaborator

Sometimes an NDA or a client preference blocks the name. Use the category instead of the person: "build by a partner agency", "site by the client's in-house team". Anonymising the party while keeping the boundary preserves the honest structure. What you must not do is let the restriction erase the boundary itself.

Rewrite one project this week

Pick the collaboration you feel most uncertain about and run it through this, in order:

  1. Write the role line first, before you look at the old copy. One sentence, under fifteen words, naming your deliverable. If you cannot write it, you do not yet know what you owned.
  2. List what existed before you arrived. Site, brand, content model, infrastructure. Anything on that list is not yours to imply.
  3. Name the other builders, or the category standing in for them if you are blocked from naming.
  4. Audit every number against whether you measured it. Delete or attribute; no third option.
  5. Re-caption every image to describe your contribution rather than the product.
  6. Move the boundary above the fold so a card, a tagline or a first screenshot already carries it.
  7. Read it as a stranger. After the title and the first paragraph, can they state what you did? If not, it is still buried.

That is roughly twenty minutes per project. The uncomfortable part is step four, which is where most portfolios have been quietly borrowing a result for years.

So: open the project you were least sure about, and read only the title, the tagline and the first image caption. From those three alone, what would a stranger think you built?

Free resource

Free SaaS MVP Scope Template

A Notion document with the full feature checklist, MVP vs. nice-to-have table, pre-build questions, and cost signals — so you walk into any developer call knowing exactly what to ask for.

Get the template →
DL

Dusko Licanin

Full-Stack Developer · Banja Luka, Bosnia

Full-stack developer shipping SaaS MVPs, web apps, and mobile apps using AI-augmented workflows — without agency coordination overhead. Live portfolio: BookBed, Callidus, Pizzeria Bestek.

Frequently Asked Questions

How do you present collaborative work in a portfolio?

Show the project, then state your role in a single sentence placed where a skimmer will see it. The structure that holds up is four facts: who built what, what you personally owned, what already existed before you joined, and which outcomes you cannot claim. Put the role line in the card, tagline or first paragraph rather than in a credits block at the bottom, because a reader who stops after the first screenshot has already formed a view. The AIGA Standards of Professional Practice require exactly this at section 5.1: no sole-credit claims on collaborative work, and no portfolio use without clear identification of the precise areas of authorship.

What should a portfolio case study say about team contribution?

It should name the other contributors and attach each deliverable to the person who produced it. A credits list of names with no roles attached is close to useless, because the reader still cannot tell which part was yours. Write it as pairs instead: build by one name, content by another, hosting by a third. If the team was large, name the major participants rather than everyone. Architecture's professional standard is a useful model here, since AIA Rule 4.201 requires members to state the scope and nature of their responsibilities accurately, with attribution no less prominent than the project description itself.

How do you credit collaborators in a portfolio?

Name them where the reader is already looking, not in a footer. A single line under the project title works: build by [name], content by you, or whatever the split actually was. Link to their site if they have one, because a verifiable collaborator makes the whole page more credible rather than less. If a confidentiality agreement blocks the name, substitute the category, such as build by a partner agency or site by the client's in-house team. That keeps the boundary visible while respecting the restriction, and it is far better than leaving a blank a reviewer has to interpret on their own.

Can you claim results from a project you only partly worked on?

Only the results you produced or measured, and only with the measurement method named. Traffic, revenue and conversion numbers from a project where you owned one layer almost never isolate your effect, so quoting them is a claim you cannot defend if anyone asks. Say what you shipped and describe the outcome qualitatively where attribution data does not exist. The direction of regulation on adjacent claims is clear: the FTC's Rule on the Use of Consumer Reviews and Testimonials took effect on 21 October 2024 and targets misrepresenting what actually happened when someone experienced a product or service.

How do you write an honest case study without making your role sound small?

Spend the words you save on vagueness describing the depth of the part you did own. A narrow, deeply explained contribution reads as stronger evidence than a broad, thin one, because it shows constraints, decisions and trade-offs a reviewer can interrogate. Describe the content model you had to fit, the editorial rules you set, the thing you tried first that did not work. Precision is what makes a partial role impressive. Vagueness is what makes a full role look borrowed, which is why portfolio reviewers screen for unclear contribution before they read your process at all.