We just merged a Kanban board into the site. That's not the interesting part. Kanban boards are commodity software. The interesting part is what we put on it: the roadmap for the site itself.
The site now contains its own development plans. And because the site is open source, that roadmap is open to contributions.
From private planning to public backlog
Like most projects, we started with a ROADMAP.md file. It listed future features, rough priorities, and vague timelines. It worked, but it was a monologue. We planned in private, shipped in public, and the gap between "what we're thinking" and "what exists" was invisible to everyone but us.
The Kanban board changes this. Visit /projects/kanban and you'll see the backlog (future features we're considering), to do (committed near-term work), in progress (what's being actively developed), recently completed (what just shipped), and the change log (historical record of major changes).
Each card links to its detailed planning document. Click a card, read the implementation approach, see the effort estimate, understand the tradeoffs.
Opening a dialogue
Here's where it gets interesting. The board data lives in content/kanban/roadmap/ as markdown cards with _board.md defining columns, and the site precompiles those into src/generated/kanban/*.js at build time. The planning documents live in docs/plans/. All of it is plain files in the repo.
This means visitors can suggest new features (open a PR adding a card to the backlog), comment on priorities (open an issue referencing a card ID), propose implementation changes (edit the plan document), and learn from the history (use the change log, card history, and commits as a paper trail).
This isn't hypothetical openness. It's the same workflow we use internally. When I want to update the roadmap, I tell Claude what changed, and Claude edits the markdown card files (or uses the kanban CLI). A visitor with a good idea follows the same path, just through GitHub's PR interface instead of conversation.
The mechanics
The board is fully functional for exploration. Drag cards around, check off subtasks, see how different arrangements feel. The "Reset" button restores the shipped default, and visitor changes don't affect the canonical roadmap. That lives in the markdown files in the repo.
Deep links let you share specific cards: clicking "Copy Card Link" generates a URL like ?card=some-id that opens that card's detail view on load. This makes the board explorable (visitors can play "what if" without consequences), shareable (deep links point to specific cards for discussion), and canonical (source of truth is version-controlled code).
If you want your changes to stick, that's what PRs are for.
Self-reference gets practical
Building this feature surfaced some recursive moments that turned out to be useful:
The Kanban board has a card for "Kanban Board" with a checklist tracking its own implementation. That card links to docs/plans/15-kanban-page.md. The plan document has a "Known Issues" section populated by code review findings. Future contributors can see not just what was built, but what's known to be imperfect.
We added a card for this blog post while writing this blog post. The meta-ness is silly, but the pattern is practical: if something is worth doing, it's worth tracking, and if it's worth tracking, it should be visible.
What this enables
Transparency without overhead. The roadmap updates as part of normal development, not as a separate documentation task. When we finish a feature, we drag a card. When we start something new, we add a card. The public view stays current because it is the working view.
Contribution paths beyond code. Not everyone wants to write code, but many people have opinions about what should be built. A public backlog with clear planning documents lowers the barrier to "here's what I think you should prioritize" contributions.
Context for future collaborators. Whether that's a human contributor or an AI assistant in a future session, the combination of board state, card history, plan documents, and commit history provides rich context without requiring synchronous explanation.
Accountability through visibility. Making the roadmap public creates gentle pressure to keep it honest. No more "Q3 2024" entries sitting in a private markdown file. If it's on the board, it's a real intention.
Try it
Visit /projects/kanban. Drag some cards around. Click one to see its implementation plan. Check the Change Log to see what recently shipped.
Then consider: what would it mean for your project's roadmap to be a conversation instead of an announcement?
If you have ideas for this site, the backlog is open. PRs welcome.