Credit Your Collaborators When Building in Public

The short answer

Credit collaborators in build-in-public updates by naming the specific work, confirming the preferred public identity and wording, and preserving the scope of each contribution. Keep founder judgment visible while distinguishing design, implementation, documentation, and selected checks. An acknowledgment should not imply a broader review or endorsement.

Credit collaborators when building in public by naming the specific work they contributed, checking how they want to be identified, and keeping the description within what they actually did. A founder can explain the product decision in their own voice while making design, implementation, documentation, and review contributions visible.

The aim is an accurate account of the work. “I chose the scope,” “we released the feature,” and “Lina designed the screen” can all belong in the same update. Each tells the reader something different. A vague thank-you is kind, but a precise role helps the reader understand how the product came together.

The release, people, roles, and sample wording below are fictional. No team project, interviews, or product tests were performed for this article. The guidance combines an original editorial example with current primary documentation on contribution recognition, checked on November 1, 2026.

Keep the founder’s point of view and the team’s work visible

A founder’s public story often follows one person because that person writes the updates. That does not mean every part of the product was their individual work. Before publishing a release story, separate your decision from the contributions that made it possible.

You might have chosen which problem to address and which tradeoff to accept. Someone else may have designed the interaction, implemented it, explained it in documentation, or challenged an assumption during review. Describing those contributions can make the decision easier to inspect without turning the post into a long team biography.

“I shipped” can describe your responsibility for a release. “I designed and implemented the feature” makes a more specific claim about work you performed. Neither first-person nor team language is automatically right. Choose the wording that fits the actual contribution, then give the reader enough context to understand it.

Buildside’s guide to building a founder brand through public product work connects the founder’s judgment with inspectable work. Accurate collaborator credit adds a useful boundary: your point of view remains yours, while other people’s work does not disappear inside it.

Look beyond the code contributor list

There are documented examples of recognizing a wider range of work. All Contributors is a specification for acknowledging open-source contributions beyond code, using a prominent public project page. Its scope is open-source recognition; it is not a required policy for every SaaS business.

The AsyncAPI project’s recognition guidance describes using that specification in its repositories. It includes documentation, ideas, issue reports, pull-request review, and answering questions among the contributions it recognizes. That is a concrete project practice, not evidence that recognition produces a particular business outcome.

The editorial lesson for a founder is to inspect the work behind the release, including work that left no code commit. A designer may have resolved the confusing interaction. A documentation contributor may have made the setup understandable. A person who reproduced a problem may have given the implementer the missing detail.

Keep the distinction between a contribution and a general association. Someone who inspired an idea did not necessarily design the final feature. Someone who answered a question did not necessarily review the implementation. Credit the help accurately instead of promoting every useful exchange into a larger role.

Prepare a private contribution-to-claim record

For an important update, make a short private note before writing the public paragraph. Record the deliverable, the person’s actual contribution, the basis for that description, their preferred public credit, and anything that should stay private. This is an editorial aid, not a performance score or a way to divide the company into percentages.

Use records you already have: a design file, a completed task, a discussion that changed the approach, or a review note. Those can help you check your memory. They do not all need to become public links, especially when they contain private project or customer information.

Then inspect the verbs. Designed, implemented, suggested, reviewed, documented, and checked describe different contributions. “Helped with the launch” may be enough for a brief acknowledgment, but use a more concrete description when the contribution explains an important part of the story.

A fictional release: a clearer client handoff view

Imagine a small client-portal SaaS preparing a new handoff view. In this invented scenario, the founder chooses the scope, Lina designs the layout, Niko implements the status filters, Sam checks selected example workflows, and Jo rewrites the setup instructions. Assume those contributions are complete and the release is available before the sample announcement is used.

A draft saying “I redesigned and built the handoff view, then tested everything” would overstate the founder’s work and the scope of the checks in this scenario. Replacing every “I” with “we” would still leave readers guessing about who contributed what.

The following is proposed copy for that fictional completed release, assuming each person has confirmed the role wording and public identity:

The new handoff view is available. I chose to focus this release on making the current status and next action easier to find, while leaving the wider project view for later.

Lina designed the handoff layout, Niko implemented the status filters, and Jo rewrote the setup instructions. Sam checked the selected example workflows described in our release notes. Those checks do not cover every possible account setup.

My next question is whether the view makes the handoff clearer in actual use. We have not measured that outcome yet.

The paragraph gives readers a product decision and an accurate account of the work. It also keeps the outcome open. None of the invented contributors is presented as having proved that the release improved customer behavior.

Confirm the name, link, and role before tagging someone

Ask the collaborator how they want the credit to appear. Confirm the spelling, chosen profile or website, and the short role description. A person may prefer a professional name, a project identity, or a contribution description without a public name.

Use the exact destination they provide rather than guessing which account belongs to them. A public credit does not need to include a private email address, location, employer detail, or an unrelated personal profile. Keep the information needed to acknowledge the work separate from information you happen to know.

There is a useful specific example in GitHub’s co-author documentation. GitHub supports Co-authored-by trailers and tells authors to obtain the email the co-author wants used, with a GitHub-provided no-reply address for someone keeping their email private. That guidance concerns commit attribution. A release update still needs its own accurate account of non-code work.

You do not need to turn every acknowledgment into a request for amplification. Credit can stand on its own. If you want someone to share or comment on the announcement, make that a separate request rather than treating the public mention as an obligation.

Keep review credit separate from endorsement

A reviewer may have checked one interaction, read a document, or challenged an estimate. State the scope when it affects the reader’s interpretation. “Reviewed the setup instructions” is different from “reviewed the product,” and “checked these examples” is different from “validated every workflow.”

The same care applies to names and logos. A collaborator’s contribution is not automatically an endorsement by their employer, a recommendation of the whole product, or agreement with every public claim. Do not add that meaning to an otherwise accurate acknowledgment.

If a person disagrees with the role description, resolve the wording before publishing it. If the disputed detail is unnecessary to the lesson, simplify the account. A public founder update should not become the place to settle an unresolved disagreement about who did the work.

Give the credit a durable home

Put the relevant contribution beside the release or decision it helped produce. A short public post can name the main roles and point to fuller release notes. Readers should be able to understand the contribution without searching through a separate launch-day thread.

The guide to writing a useful public SaaS changelog explains the durable release record. Add credits where they clarify that record. Keep the customer-facing explanation readable rather than surrounding it with a long list of tags unrelated to the change.

When you reuse the story in a newsletter, demo description, or later founder post, check that the shortened version still describes the work accurately. You can shorten the detail while retaining the essential distinction between your decision and a collaborator’s contribution.

Private evidence can remain private. The guide to building in public without oversharing covers separating a useful lesson from sensitive detail. An agreed role description often communicates more clearly than a screenshot of internal tickets or private messages.

Correct missed or overstated credit plainly

If a contributor was omitted or a role was described incorrectly, check the correction with them and update the relevant public account. Explain the changed attribution where readers would otherwise retain a misleading impression. Do not quietly replace one exaggerated claim with another.

AsyncAPI’s recognition guidance explicitly invites people to report missed credit so it can be fixed. That illustrates a correction route within a project’s process; it does not prove its records are always complete. A small SaaS team can likewise make it clear where a collaborator should raise an attribution error.

Keep the correction specific. In the fictional example, a correction could clarify that Lina designed the layout while Niko implemented the filters. It would not need to publish private messages, fees, performance judgments, or a ranking of whose effort mattered most.

Buildside’s About page describes sharing SaaS progress and finding useful collaborators. Accurate credit can be part of that public record. Buildside publishes this Journal; this suggested practice does not imply that the platform verifies contributor roles or manages release credits automatically.

Before your next public update, underline the verbs that describe who did the work. Check the contribution behind each one, confirm the preferred public credit, and keep the product lesson clear. That leaves readers with a better account of both the decision and the people who helped make it real.

Questions founders ask next

Should every contribution receive a percentage?

No. A role-specific description can acknowledge the work without inventing a precise division of effort. Percentages require a defined basis and should not be added merely to make the credit look objective.

Can I credit someone who prefers not to be named?

Discuss the wording they are comfortable with. An agreed role description without a name may work. Keep private identity details out of the public update, and do not tag an account they have not chosen for that credit.

Do I need to publish source code to explain a collaboration?

No. A public description can explain who designed, implemented, documented, or checked the relevant work without exposing the underlying files. Share only the materials appropriate for that public account.

Sources

All Contributors: Recognizing work beyond code

AsyncAPI: Contributor recognition and missed-credit corrections

GitHub Docs: Co-authored commits and preferred identity information

Buildside: About the community and publishing approach

Frequently asked questions

A note from Uriel Bitton

This guide combines primary contribution-recognition documentation with an original fictional release example. No team project, interviews, or product tests were performed for this article. Buildside publishes this Journal.

Keep building with us

Get practical founder lessons and product updates in your inbox.

Subscribe or Join Buildside.

Keep reading