Here’s a scene every small dev team knows. You open Miro or FigJam to sketch the data model. Forty minutes later the sketch is good, the decision is made — and then someone spends another twenty minutes translating it into tickets on the board, where it will slowly stop resembling the sketch. Two weeks on, the whiteboard is stale, the board is the truth, and nobody can reconstruct why the decision went that way.
A slow clap for the translation tax.
We built Kahoona with a whiteboard sitting next to the project board because we think that split — thinking in one tool, tracking in another — is a bug in how teams work, not a feature of it.
The translation tax
Every handoff between tools costs two things. The first is time: the twenty minutes of ticket-writing after the sketch. Annoying, but survivable.
The second cost is worse: context loss. The whiteboard holds the why — the arrows you drew and erased, the option you crossed out. The tickets hold the what. Once they live in different tools, the link between them decays within days. New teammates inherit the what and guess the why. We’ve been that new teammate. The guessing is expensive.
What actually changed when we merged them
We’re not going to pretend a whiteboard beside a board rewired our brains. Three concrete things changed:
Design sessions end with tasks, not homework. You sketch the flow, box the piece that’s a task, and it’s on the board. The translation step doesn’t disappear — it shrinks to the moment the idea is still warm.
Stale diagrams get deleted instead of worshipped. When the sketch lives next to the board, staleness is obvious. In a separate tool, a stale diagram just sits there accruing false authority. We’ve been burned by year-old Miro frames treated as spec. Never again.
PR review gets a place to point. “This doesn’t match the shape we agreed” becomes a link to the sketch next to the ticket instead of a paragraph in a review comment. Disagreements about intent resolve faster when the intent has an address.
The honest trade-off
A whiteboard inside a project tool will never beat a dedicated whiteboard at being a whiteboard. Miro and FigJam have deeper shape libraries, better facilitation features, real-time cursors polished over years. If your team runs structured workshops with outside stakeholders, keep the dedicated tool. We do, occasionally.
The bet we made is that for a small dev team, 80% of whiteboarding is thinking out loud about the work — data models, flows, sequences — and that 80% belongs where the work lives. The remaining 20% can afford a second tool. The reverse bet — all whiteboarding in a separate tool — taxes the 80% to serve the 20%.
The principle underneath
This is the same bet as the rest of Kahoona: the board should sit next to the evidence. Commits and PRs stream in next to the tasks so the board stays honest. The whiteboard sits next to the board so the reasoning stays honest too. Tools fragment; work shouldn’t.
👉 Whiteboard, board, and live GitHub activity in one workspace — free to start: kahoona.app
Related: Why Commits Belong Next to Tasks · Jira Shows Tickets, Not Truth