Doop

Doop gives you a multiplayer canvas where you and AI agents can design UI components side-by-side. The MCP server is a strong idea, letting any compatible agent stream designs directly into frames, and the built-in agent handles basic tasks well. The experience is about live collaboration and iteration, not creating polished, multi-file components; it generates HTML in sandboxed iframes, not a full project structure you can check into a repository.

This is a great tool for teams to quickly visualize ideas with AI assistance. Pick Doop if you want a shared whiteboard for web UI concepts. If you need an agent that builds production-ready code in your actual repository, you should use a different tool entirely.

The AGPL-3.0 license requires any user who modifies the code and runs it on a network to make their source code available. This applies to self-hosting a modified Doop instance. A company using a modified version to collaborate on proprietary designs would have to release its modifications. This licensing choice walls off a large segment of the intended user base.

The application does run agents in sandboxed iframes. It also supports multiple agent providers and allows users to bring their own keys, which contains cost. It is a true multiplayer design tool.

Doop presents a multiplayer design canvas where AI agents, acting as collaborators, stream HTML into sandboxed iframes. The architecture is explicit: agents connect via a built-in MCP server, and verification is performed through a self-review loop where agents critique screenshots of their own output. This design is documented and observable, a welcome distinction from systems that obscure their methods.

This approach confines the tool to UI generation and does not interact with a local filesystem or version control. While this ensures a controlled environment, it limits its application to design ideation rather than direct code implementation. The absence of benchmarks is noted, though the clarity of the architecture allows for a direct assessment of its capabilities.

Doop is an impressive piece of engineering, especially for what appears to be a solo founder project. The multiplayer architecture and MCP server for agent collaboration are well-executed. The AGPL-3.0 license and BYOK model are smart ways to build a community and defer costs, but they don't constitute a business model. This is 'open source as a marketing plan'—it attracts developers and early adopters but doesn't build a moat or generate revenue.

Without a clear path to monetization or venture backing, the project's longevity is tied directly to the founder's runway. The most probable exit is an acqui-hire. A company like Figma or Adobe could be interested in the MCP protocol and the talent behind it, integrating the core ideas into their existing platforms. The AGPL license makes direct code acquisition complicated, favoring a talent grab.

The demo shows a multiplayer design canvas. The pricing model is bring-your-own-key, which translates to sixty individual developer subscriptions or API keys. This is an unbudgeted, uncapped operational expense on developer credit cards, which is a known procurement anti-pattern. The open source AGPL-3.0 license and self-hosting option are noted, but the lack of SSO, SCIM, or audit logs makes it unsuitable for team-wide deployment.

This tool introduces an unmanaged, metered cost center and lacks the basic controls required for a team of our size. The onboarding cost is not training, but the process of getting sixty developers to expense and manage individual AI model subscriptions. Not yet.

Doop gets a lot right. The AGPL-3.0 license is honest, and I can docker compose up or bun run dev to get it running on my own machine. It's built around a proper protocol, with both an MCP client and server, so I can connect external agents to its canvas. That's the kind of extensibility I look for; it's not just a walled garden pretending to be open.

The catch is model freedom. While it supports bringing your own key for OpenAI and Anthropic models, there's no path for local models. That means no air-gapped design sessions and a persistent dependency on someone else's API. It's a solid project, but until I can point it at an Ollama endpoint, it's not fully mine.