Lessons from building multiplayer browsers

Alejandro García Salas, a founding engineer, recounts his journey and the profound lessons learned from building two ambitious startups, Sail and Muddy, which aimed to revolutionize personal computing through "multiplayer browsers." Despite significant seed funding and a technically sound foundation, both products struggled to find widespread adoption and ultimately did not succeed.

• Sail's Vision: Initially conceived as an infinite canvas app with a built-in browser ("Spatial Notion"), Sail allowed users to collaboratively browse and place live websites. It struggled with a broad public launch, highlighting the danger of working in secret for too long.
• Muddy's Evolution: After the "multiverse project," Muddy emerged as an integrated work environment combining Slack and a browser, aiming to innovate chat with embedded tabs. However, its positioning too closely resembled Slack, failing to offer a compelling reason for users to switch from established, "good enough" solutions.
• Positioning Predicament: The core challenge for both products was effectively communicating their unique value proposition. The market tended to reduce complex visions (like a browser as a "metalayer for communication") to simplistic, often unappealing, descriptions ("Miro but with websites").
• The Multiplayer Graveyard: The author notes that many ambitious multiplayer products, from Google Wave to Tandem, have failed as standalone offerings, suggesting that work is often more siloed than idealist visions predict.
• "Best Polished Version" Trap: Attempting to build a "better version" of an already good-enough product (like Chrome or Slack) faces immense switching costs and ingrained user habits, a hurdle that both Sail and Muddy encountered.
• Technical Strength vs. Market Need: While the underlying architecture—streaming DOM mutations and a flexible sync engine—was technically clever and enabled rapid prototyping, the bottleneck was never technical. The challenge lay in identifying genuine user needs and market demand.
• Dogfooding's Deception: Running the company on their own products provided internal validation of usability but offered little insight into whether external users would adopt it. The team, having invented the concepts, could navigate complexity that new users found overwhelming.
• "Early Early" Realities: The author contrasts the messy, uncertain reality of early-stage development (like Notion's rebuild in Kyoto or Figma's years of engine development) with the sanitized, post-success narratives, emphasizing that real early stage lacks clear shape.
• Reps, Theses, and Truth-Seeking: A startup's thesis should act as a compass, not a fixed destination. The key to progress lies in relentless truth-seeking, iterating based on user signals rather than solely on the compelling internal logic of a thesis, likening it to the iterative practice of figure drawing.

The story concludes by emphasizing that true learning and growth in startup building come from consistently "getting reps in"—shipping, testing, and adapting based on real-world feedback, even when individual attempts fail to achieve product-market fit.