Case file — 4EDE266D
Launch roast · Show HN
Whiteboard (YC W26) – An open-source IDE for thoughtful software design by sidharthkmenon · HN thread
Unsolicited, from public launch info only. Founder? Reply or ask us to take it down.
The idea
“Whiteboard (YC W26) – An open-source IDE for thoughtful software design https://github.com/devdotfast/whiteboard Founder's Show HN post: Hello! We’re Sid, Alex, Ketan, and Milan. We’re building Whiteboard (https://whiteboard.dev.fast/), an open-source desktop app where humans and agents can architect software together in a common workspace. Here’s our repo: https://github.com/devdotfast/whiteboard. We were missing the feeling of a “whiteboard session” with another dev where you leave with a deep understanding of a system, so we built this app for ourselves. Whiteboard plugs into the tools you already use - e.g. Claude Code, Codex, etc. – and gives your agent an SDK to draw on an in-app canvas to describe its work. We began with an MVP based on HTML artifacts and started rethinking the app as we ran into limitations: 1. Built on top of CodeOSS: We found that in pure HTML tools it was hard to connect a spec or diagram to code. In Whiteboard, when you click on visualizations like a sequence diagram, an entity relationship diagram, or a quote from the agent’s trace, you can jump to the underlying code directly. When navigating code, you get keybindings and LSP support from VSCode out of the box. We’ve found this is especially valuable because tradeoffs are often only discovered after a first pass at implementation (re: slop) 2. Semantic diff viewer: we wrote a semantic, AST-aware diff viewer in Rust so you can only view the code changes which are relevant to you [1]. We’ve set up some sane defaults: large added functions are summarized as pseudocode, and things like unit tests and large documentation changes are collapsed / hidden. This is all customizable with a WASM-based plugin system. 3. Decision Log: We found it difficult to reason about what set of decisions our agents made autonomously. So we built tools for agents to query and link their own traces to the Whiteboard, so you can understand how the requirements that you set were implemented, and understand what decisions your agent made autonomously. Here’s a quick demo video explaining more: https://www.youtube.com/watch?v=ChPn3ftULWE Folks Landing page content (devdotfast/whiteboard): # devdotfast/whiteboard open-source canvas for thoughtful software design - Stars: 2893 - Forks: 141 - Watchers: 2893 - Open issues: 34 - License: MIT License - Homepage: https://whiteboard.dev.fast/ - Default branch: main - Created: 2026-08-18T15:06:04Z ## Languages - Batchfile - C++ - CSS - Dockerfile - Go - HTML - Inno Setup - JavaScript - Nix - PowerShell - Python - Roff - Rust - SCSS - Shell - Tree-sitter Query - TypeScript ## Top Contributors - thesiti92 (342 contributions) - ketan0 (159 contributions) - sidkmenon (55 contributions) - milanb17 (46 contributions) - dependabot[bot] (43 contributions) - github-actions[bot] (19 contributions) - detail-app[bot] (11 contributions) - KappaShilaff (8 contributions) - LeFelps (1 contributions) - itsWill (1 contributions) --- ## README Whiteboard an open-source canvas for thoughtful software design Download for macOS, Windows, and Linux · Website · Roadmap · Discord Whiteboard is an open-source desktop app where humans and agents can architect software together in a common workspace. Whiteboard plugs into the tools you already use - e.g. Claude Code, Codex, etc. – and gives your agent an SDK to draw on an in-app canvas to describe its work. Here’s a 1 min demo video explaining more: https://www.youtube.com/watch?v=ChPn3ftULWE ## Quickstart 1. Download Whiteboard and open the app. On macOS you can also run `brew install --cask devdotfast/tap/whiteboard`. 2. Connect Claude Code, Codex, or another coding agent from the welcome screen. 3. Ask your agent to review your current branch against up-to-date main and open the result in Whiteboard. ## Guidance In our experience, Whiteboard works best with models like GPT-6 Sol and Claude Opus 5.5 for their intelligence, cost, and speed tradeoff. Here are a few example prompts of how to use Whiteboard effectively. We are working hard to make sure the right choices are baked in by default to the system prompt - part of why this system is open source! - but in the meantime: ### For a new API change > hey, this stack of commits is set up so i can get an [api] to do [objective] > > i'd like to see: > > - proposed api > - examples > - motivations for this (if available to you in context/in the repo) > > and then we can dive into implementation + explaining how things worked. ### For a change to add telemetry: > Can you explain to me the telemetry changes form the newest posthog pr https://github.com/devdotfast/whiteboard/commit/4”
The bull case
A skeptic who got convinced would say this: every agent vendor will build its own walled-garden review view, but teams use more than one agent and none of those vendors will review a competitor's output well. A neutral, open layer that shows what any agent decided, linked to the code it touched, is the kind of surface that becomes a standard, much as the open-source tool that sat across vendors often beat each vendor's native version. Add a distribution engine that costs nothing (HN, GitHub, Discord), low hosted COGS because users bring their own inference, and a trajectory-storage tier that gets more valuable the more reviews flow through it. That's a credible path to a team-level product if shared review becomes a habit.
The panel
Grounded in live search01 Market
mixedNo market-size or funding data was returned, so I can't say whether the category is growing or saturated. The only live source is the founders' own HN post, and it names no direct competitors. Claude Code and Codex appear as integration targets, not rivals, which also makes them a dependency. The most serious risk is that agent vendors or existing IDEs add native diagram, diff, and decision-trace views, which would erode a layer that sits on top of their tools. The planned revenue (a hosted web version with trajectory storage and multiplayer reviews) is also unproven. The strongest advantage is early developer pull: 424 HN points, 143 comments, about 2.9k GitHub stars, an MIT license, and an agent-agnostic design built on a familiar CodeOSS base. That is demand signal, not yet a moat.
02 Tech
mixedThe hardest problem is anchoring agent-drawn diagrams and decision-log quotes to code that keeps changing. Clickable sequence diagrams only work if links survive edits, and the AST-aware Rust diff has to handle many languages through Tree-sitter grammars. The commit history shows a strong core engineer (342 commits), so this looks feasible. Forking CodeOSS is the right call for LSP and keybindings. The cost is a permanent upstream-merge burden and no access to Microsoft's extension marketplace. The moat is thin. The MIT-licensed shell and thin agent SDK are copyable, and Claude Code or Codex could ship canvases themselves. Any defensibility lies in the semantic diff and the trajectory data behind the planned hosted tier, which isn't built yet. The best-chosen piece is the WASM plugin system on the diff viewer, which makes the defaults customizable without forking.
03 Finance
mixedCAC is the strong part: 2,893 stars and a 424-point HN launch mean developer acquisition is nearly free. The gap is conversion. The desktop app is MIT and the hosted tier (trajectory storage, multiplayer reviews, session management) has no stated price, and "everything stays self-hostable" lets any team skip paying. Per-seat pricing around $20-40/month (my rough estimate) only works if shared review becomes a team workflow, and that sits next to code-review tools buyers already pay for. Expect a low free-to-paid rate and a long path to a team-level budget. With no revenue, a standard YC raise (roughly $500k, an estimate) at a four-person burn of about $50-60k/month (also an estimate) gives about 8-10 months, so a paid hosted pilot is needed within roughly six. Hosted COGS stay low because users supply their own agent inference.
04 Timing
strongWell-timed, slightly early on monetization. Agents now write code faster than humans can understand it, so the bottleneck has shifted from generation to comprehension and review. Whiteboard targets that gap, and its Show HN (424 points) and roughly 2,900 stars in about seven weeks suggest developers feel it. The macro trend that matters most is agent vendors absorbing review and visualization into their own products. Whiteboard's bet is that a neutral, open layer across Claude Code, Codex, and others beats each vendor's walled version. The window is open but closing: the big agent makers and VS Code-based editors can ship diff summaries and diagrams quickly. The favoring factor is that developers are actively burned by "slop" and want to see agent decisions, so demand exists now.
Risks to manage
The vendors you plug into can ship your layer
The Market and Timing agents both flagged platform absorption. Agent makers and VS Code-based editors can add diff summaries, diagrams, and decision traces much faster than you can build a company. The window is open, but your thin agent SDK and MIT shell are copyable. Your defense is neutrality across agents, and that only matters if teams really run several agents at once.
The monetization is unpriced and easy to route around
The desktop app is MIT, the hosted features are self-hostable, and no price exists. The Finance agent's rough estimate of $20-40/seat/month only works if shared review becomes a team workflow that sits next to review tools buyers already pay for. Stars are not budget. On the panel's estimated $500k raise and $50-60k monthly burn, you have roughly 8-10 months of runway (both figures are estimates), so you need a paid hosted pilot within about six.
Keeping diagram and decision-log links alive as code changes
Clickable sequence diagrams and trace quotes are the whole pitch, and they only work if the anchors survive edits. Add Tree-sitter grammar coverage for many languages and a permanent CodeOSS upstream-merge burden, and a small team's roadmap gets eaten by maintenance. One diagram that jumps to the wrong line will cost you more trust than ten good ones earn.
Blind spot
Your product is only as good as what the agent chooses to draw, and today that depends on the user prompting well. Your own README ships example prompts and admits the "right choices" aren't yet baked into the system prompt. A new user who connects an agent, gets a mediocre canvas, and shrugs will never reach the semantic diff. Stars measure curiosity about the idea, not repeat usage of the output. You also ask developers to open a separate IDE for the review step, and people with habits in their editors and terminals rarely move for a "better view" of something they can already skim.
What would need to be true
Teams routinely use more than one coding agent, and they value a neutral review layer enough that agent vendors' native views don't satisfy them.
Teams will pay for hosted shared review and trajectory storage even though everything is self-hostable, because the workflow is collaborative and someone owns the budget.
Diagram and decision-log anchors stay accurate through real code churn, and default agent outputs are good enough that new users reach the "aha" without hand-tuning prompts.
Actions to take this week
Pull your PostHog data this week and measure the funnel: installs, agent connected, first canvas opened, second session within 7 days. A positive signal is roughly 20%+ of installers returning in week two (my threshold). If it's under 5%, fix defaults before anything else.
Message 15 of the 143 HN commenters, or Discord members, who lead or review on teams using agents. Ask: "Who reviews agent-written PRs on your team, how long does it take, and who signs off on tools that cut it?" A positive signal is 3+ naming a budget owner or asking for hosted access.
Put a price on the hosted tier now: a waitlist page with a stated per-seat price (try $25/seat/month, an estimate to test) for shared trajectory storage and multiplayer review. A positive signal is 30+ signups from company email addresses, or 3 teams willing to sign a pilot LOI.
Time 5 real agent-generated PRs reviewed with your semantic diff and decision log versus a standard diff, using reviewers who didn't write them. Publish the time and error-catch numbers. A positive signal is a clear reduction (for example, review time cut by a third or more) that you can put in front of a team lead.
Make anchoring reliability a visible metric: run your diagram and trace links across 20 commits of edits on a real repo and count how many still land on the correct code. Fix the failure cases before you scale installs.
Work through these, then roast the idea again with what you learned.
No account needed. One email, no follow-ups.
Your idea is next
What would the panel say about yours?
You just read what four AI examiners found in someone else's idea.
Your startup has a fatal flaw. Find it before you build.