Map

Sail & Muddy โ€” Get Your Reps

Wiki summarystartupsproductdesignbrowsersmultiplayer โ†ณ show in map Markdown
title
Sail & Muddy โ€” Get Your Reps
type
summary
summary
Alejandro Garcia Salas's retrospective on four years building a multiplayer browser โ€” positioning, dogfooding traps, "best polished version" strategy, and reps as the only way to learn
tags
startups, product, design, browsers, multiplayer
created
2026-05-06
updated
2026-07-22

Alejandro Garcia Salas joined Sail in 2022 as a founding engineer after Ron and Jimmy raised a $5.5M seed from General Catalyst, Naval, Lachy Groom, and YC. The team had already done the genuinely hard part โ€” forking Chromium and figuring out how to build a product UI on top of it in HTML/CSS/JS. The remaining hard part, what to actually build, never got solved. Sail was an infinite-canvas multiplayer browser ("FigJam or Miro with a browser built in"). It pivoted through what the team called the "multiverse project" (canvas, structured-canvas, chat, all on the same sync engine) and ended up as Muddy ("Slack and a browser as an integrated work environment"). Neither shipped to enough users to grow. Source: sail-muddy-lessons.

The post is long because it's not really about Sail and Muddy. It's about which lessons survived four years of failed reps, framed for the next attempt.

What didn't work

The thesis was Kevin Kwok's Arc of Collaboration โ€” that collaboration should be a metalayer across all productivity apps, with the browser as the natural home. It was internally compelling enough to become hard to question. Each iteration started from "how do we make this thesis work" instead of "what are users actually doing." Alejandro is explicit: a thesis is a compass, not a destination, and proof only happens when each shipped version teaches you something that changes the next one.

Multiplayer-by-default kept hitting the same wall it hit for Tandem, Multi, Screenhero, Google Wave, Microsoft Loop, and Safari Shared Tab Groups. "Most people don't feel a need to talk to their co-workers that often." Work is more siloed than the people building collaboration tools want to believe. See multiplayer-by-default-failure.

Positioning was unsolvable for the same reason it was unsolvable for Arc and Mighty. The market reduces ambitious framings to short descriptions: Arc โ†’ "pretty browser with a sidebar," Mighty โ†’ "fast Chrome on the cloud," Sail โ†’ "Miro but with websites." There was no anchor use case underneath the grand vision the way Notion has "wiki / docs / project tracker" under "tool for thought." See positioning-vs-vision-gap.

Sail did "platonic decomposition" โ€” finding the smallest set of primitives (web cards, text cards, comments, messages, threads, notifications) that compose into everything. Elegant for builders. Useless for users, who reacted with "that's cool" and didn't adopt. System-driven design impresses developers but purpose-driven-vs-system-driven-design is what users need.

Dogfooding became a trap. The team migrated off Discord, off Linear, off most of Notion. It felt like validation. It wasn't โ€” they understood every concept because they invented every concept, and external users hit the same "what am I supposed to do with this?" wall. See dogfooding-trap.

What he'd do differently

Two specific tests he wishes they'd run earlier. The landing page test: force yourself to write a real landing page that has to sell to a stranger, not a pitch deck. If you can't fill it, you don't know what you're building. The Sandwich Video test: imagine the Slack launch video version of your product. What scenes? If you can't picture it, that's the signal. Both exercises came too late.

He's also direct about launching. Sail never had a broad public launch. He cites Paul Graham's frame: working in secret on a rocket engine is fine; working in secret for a year on a social product is probably going to flop. No one cares about your launch โ€” Brian Chesky's line: "if you launch and no one notices, you can just launch again." Airbnb launched three times.

The "best polished version" strategy (Linear for Jira, Vercel for frontend DX) only works when the existing tool is bad enough. Chrome is good enough. Slack is good enough plus integrations and switching cost. Trying to replace both at once was the combined-friction trap.

Reps as the actual asset

The post's title is "Get Your Reps." The argument is that pattern recognition from many real attempts โ€” not stubbornness, not vision โ€” is what makes second-time founders faster. Parker Conrad built Zenefits, started Rippling six weeks later. Karri Saarinen had Kippt, Coinbase, Airbnb before Linear hit PMF in a year. Notion's "early days" everyone references skip the part where Ivan Zhao laid off the team, sublet the office, moved to Kyoto, and rebuilt from scratch. Figma had four years of stealth WebGL R&D before anyone saw a product. See early-stage-reality and reps-as-pattern-recognition.

The figure-drawing analogy threads through. Work evenly across the piece so you can stop at any time and be done โ€” don't render the hand beautifully while the torso is a stick figure. They iterated on three+ versions of the sidebar while the rest of the product was barely there. Brand work for Sail was timeboxed too loosely; Karri's Linear approach (pick a name, color, typeface, move on) is the discipline they didn't have.

Cross-references