Public Kanban Boards — Share Your Project Status by Link

A public board is not just a roadmap with extra steps. It is how open-source projects show what is being worked on, how agencies give clients live status without a license, how small teams broadcast progress without writing a blog post. The hard part is not making a board public — it is making sure members-only data stays members-only. Here is the read-only pattern we shipped, the data we chose to hide, and how it compares to Trello and Notion.

A public kanban board is the cleanest way to share project status at scale. Send one link; everyone gets the same live view. No accounts, no invites, no “let me export the latest version.” But most public-board implementations get the privacy boundary wrong — either they expose too much (comments, member names, internal discussion) or too little (a static snapshot that is out of date the moment you share it).

This is the pattern we shipped for Kangram’s public boards, the data we deliberately hide, and how it stacks up against the alternatives.

When a public board makes sense

Three use cases where public boards beat every alternative:

1. Open-source project status. Contributors and users want to see what is in progress, what is blocked, what is shipping next. A public kanban linked from the README replaces the “where is the roadmap?” question permanently.
2. Agency to client visibility. Clients want to know what you are working on without learning your tool. A public board per engagement gives them a live URL they can bookmark. No license seat, no onboarding.
3. Internal team broadcasts. A team lead shares progress with stakeholders (sales, leadership, adjacent teams) without granting write access or training them on the tool.

The unifying property: the audience is read-only and the data is the message.

Anatomy of read-only

A public board must satisfy three invariants:

1. Reads work for anyone with the link. No login, no membership check.
2. Writes stay gated. Only board members can create, edit, move, or comment.
3. Members-only data stays hidden. Comments and the member roster are not exposed.

In our codebase the pattern is two functions:

// BoardsReader — short-circuit membership for public boards
async function isBoardPublic(board: Board): Promise<boolean> {
  return board.visibility === "public";
}

// Every mutation gate checks writability
async function assertBoardWritable(board: Board): Promise<void> {
  if (board.archivedAt) throw new ExtError(409, "Board archived");
  // public reads OK, but mutations still require membership — checked elsewhere
}

Public boards share one auth path with private boards for reads. Mutations route through assertBoardWritable and a membership check — the visibility flag controls reads, not writes.

What we hide on public boards

Not all task data is safe to expose. Two fields are explicitly suppressed:

Field	Reason
Task.comments	Internal discussion often names people, links private docs, or contains deliberation
Board.members	The member roster exposes who is working on what — collaborator privacy

Task fields that ARE exposed: title, description, status, priority, assignee (if set), tags, deadline. These are the public-facing project state. The rest stays internal.

Decision note: we considered exposing comments by default with a “private comment” toggle. Rejected because it puts the privacy burden on every comment author, every time. The safer default is hide-all; expose selectively later if a real use case emerges.

Visibility toggle and canonical URLs

The user-facing flow is one toggle in board settings: Private (default) becomes Public. The moment a board flips to public, its canonical URL (kangram.app/:ownerSlug/:boardCode) becomes readable by anyone.

Two design choices that mattered:

• Canonical namespace URL. Not /boards/123 — that is an internal ID. The URL should be kangram.app/acme/Roadmap so it is shareable, memorable, and crawlable.
• Toggle is owner/admin-only. Only people with manage permission can flip visibility. A regular member should not accidentally broadcast the board.

Comparison with Trello and Notion public sharing

Feature	Trello Public	Notion Shared	Kangram Public
Read by link	Yes	Yes	Yes
Account required to read	No	No	No
Comments exposed	Yes	Optional	No (privacy default)
Member roster exposed	Yes	Optional	No (privacy default)
Writes gated	Yes	Yes	Yes
Canonical URL	trello.com/b/<random>	notion.so/Workspace-<slug>-<hash>	kangram.app/<owner>/<code>
SEO-indexable	Yes	Yes	Yes
Toggle per board	Yes	Yes	Yes

Trello and Notion expose more by default. Kangram hides comments and members by default — a deliberate privacy choice for teams who want to share progress without exposing internal discussion.

FAQ

Q: What is a public kanban board? A: A kanban board with visibility set to public, readable by anyone with the link without an account. Writes stay gated to board members; only the task data itself is exposed.

Q: How do I share a kanban board by link? A: Set the board’s visibility to public and share the canonical URL. In Kangram the URL is kangram.app/owner-slug/board-code — short, shareable, crawlable.

Q: Are comments and members visible on a public board? A: They should not be. A well-designed public board exposes task data but hides comments and the member roster to protect collaborator privacy.

Q: Can I make a public board indexable by search engines? A: Yes. Public boards are server-rendered and have canonical URLs, which makes them crawlable. Use this for roadmaps and OSS project status, not for internal work.

Q: Can I revoke public access later? A: Yes — flip the visibility back to private. The URL stops serving content to non-members immediately.

Conclusion

A public board is the right primitive for project status, roadmaps, and OSS task lists. The implementation work is small once you split the read path from the write path and decide which fields are members-only. Hide comments and members by default; expose task data only; make the URL canonical and shareable.

→ Telegram bot for task management · MCP vs REST API · Try Kangram