Get Your Reps - Alejandro García Salas

product, design, and engineering lessons from building Sail & Muddy Published March 2026 In 2022 I was looking for a very specific thing: a small team, less than ten people, before product market fit, working on something I actually cared about. I started coding early on and have always loved building and computers. I was interested in startups and in the future of personal computing. Two friends from college, Ron and Jimmy, reached out. They'd been working on this idea of a new browser, forked Chromium, figured out how to build on top of it, and raised a 5.5 million dollar seed from General Catalyst, Naval, Lachy Groom, YC, and others. By the time I joined as a founding engineer one of the hard parts was done. You could build on top of Chromium, access tabs, the history API, and all the UI could be built with web technologies. But the other hard part was still ahead of us: what to build, how it should work, and whether anyone wanted it. I've always loved the philosophy of the open web, and I'm deeply grateful for it. I love frontend engineering and I'm very product minded. Getting to build on top of Chromium, millions of dollars in R&D forked from earlier browser engines × Chromium was forked from WebKit, which was forked from KHTML. One of my favorite things about the codebase: the C++ source files have stacks of copyright notices from different organizations dating back to the 90s, everyone adding their own signature on top of older and older code. Standing on the shoulders of giants. , felt both humbling and like an experience that would really stretch me. We were aiming to build a window worthy of the work you do and the work you do with other people. That evolved into collaborative software: realtime multiplayer, infinite canvases, rich text editors, chat, all packaged into the browser alongside web content. Framed as a "multiplayer browser" or "team browser," it was an attempt to channel venture dollars into a new kind of personal computing company. Sail, and later Muddy, were the products that came out of that vision. Lots of people want to build new computing paradigms, new interface ideas. We gave it a real shot. Past flashy demos and hypotheticals.

We studied both the history of personal computing and your favorite productivity software (Slack, Notion, Linear, you name it), talked to users, built new interfaces, shipped them, and watched most of them not work. Building and maintaining a browser product was unusually hard, and even though it did not work out as a company, the team proved a lot and learned a lot. Building a startup forces you to see past the grand vision. We failed to make something that a lot of people wanted and could grow. But I came out of it a fundamentally better product thinker, engineer, designer, builder, and hacker than when I went in. I got my reps in. Here's what I took away. What We Built Positioning The Graveyard and "The Best Polished Version" Under the Hood: Technical Bets and Dogfooding Early Early Reps, Theses, Secrets, and Proof of Work What We Built When I joined, Sail was a very much in progress infinite canvas app built on top of our own Chromium fork × I learned a lot about browsers working on this. Chromium University is a great resource. A lot of the talks that Chromium developers share with each other are available online freely and are pretty fun to watch. . You could put websites in, add some text cards, see people's cursors, but it was still taking shape. Positioning wasn't locked in yet, and there were features to build out and bugs to fix. We iterated on it and drew inspiration from Muse × Adam Wiggins wrote an excellent retrospective on Muse. Worth reading in full if you're building in this space. , Kinopio, and a lot of other infinite canvas apps I can't even remember all of, riding the energy of the canvas moment when Miro and FigJam were surging. A fun positioning we talked about at some point was "Spatial Notion." Sail was the most fun version and what got me to join. Using it felt magical. Browsing the web and feeling like it's the web, not a streamed video feed like you would in a Zoom screenshare, seeing other people's cursors and imagining how everyone could actually be doing work in the same canvas side by side, having these random encounters like you often do in Figma when you browse the same design file. It felt super cool. But cool demos, cool visions, and cool feelings aren't always enough.

Though of course, sometimes they can be. Sail: "FigJam or Miro with a browser built in, you could place live websites on an infinite canvas and everything was multiplayer." Sail never got a broad public launch. We tested it with different types of users looking to make themselves more productive, but there's a chance we failed to reach a specific type of user that would have loved Sail. I really wish we had launched more widely × Paul Graham nails this: "The danger of working in secret is inversely proportional to the simplicity and precision of the test. It would be safe to work in secret for a year on a new rocket engine. But if you work in secret for a year on a new social network, it will probably be a flop." . No one cares about your launch. Taking too long to launch builds up pressure. You start protecting a reputation you haven't earned yet. And if you take too long, you give yourself fewer chances to relaunch. Brian Chesky × "If you launch and no one notices, you can actually just keep launching." Airbnb launched three times before it got traction. said it best: if you launch and no one notices, you can just launch again. After Sail we went through what we internally nicknamed the "multiverse project," a version that supported different kinds of boards: infinite canvas, structured canvas (Nototo-style), and chat. Because it was all built on the same sync engine, trying different form factors was relatively easy. We even got to the point where you could reference usable instances of one board type inside another. It was cool. It also got really complex. Chat is what survived, and it became the foundation of Muddy. The "multiverse project": chat, canvas, embedded websites, and multiple board types all at once. It got complex. Muddy: "Slack and a browser as an integrated work environment." Chat is lindy × The Lindy effect: the longer something has survived, the longer it's likely to keep surviving. Chat as an interface has been around since IRC in the 80s. It's not going anywhere. . People understand it immediately, it's legible, it caters to a lower common denominator more easily than a canvas, and it transfers to mobile. We had a React Native app on TestFlight, built with help from contractors. The scope and table stakes for productivity software keep going up, people expect a mobile companion app.

But we overindexed on table stakes. In hindsight, we should have tackled the harder problems around positioning head on rather than working on the mobile app. The positioning got us too close to Slack, and you risk just being another chat app. Muddy's embedded tabs in chat were genuinely good. I believe we innovated in that UX and I'd love to see something like it in apps like Slack. But forward-looking UX doesn't always win. The final UI of most apps has inefficiencies, things that aren't really optimal, and people are fine with that. A better interface isn't enough reason to switch if the current one is good enough. A lot of people have tried to beat Slack (more on this soon). Positioning Part of the company's thesis was shaped by Kevin Kwok's The Arc of Collaboration, the idea that collaboration should be native to productivity apps, not a separate layer, and that there's room for a metalayer across all of them. It's a thought-provoking read. Kwok argues that Slack is "911 for when everything falls apart," not air traffic control, and that the real opportunity is a layer that sits across all your apps handling presence, collaboration, and identity. That's essentially what we were trying to build with the browser. It made a lot of sense on paper. I see it differently now, but at the time it was a strong inspiration. From Kwok's Arc of Collaboration: functional workflows (Figma, Google Docs, etc.) each with collaboration built in, and a Discord-type metacommunications layer sitting across all of them. We had some version of this diagram internally, with the browser as that metalayer. Charts like this can be compelling, and this one was. The key is to know how to look beyond it and keep poking holes, experimenting, testing against reality. More on this in Reps, Theses, and Proof of Work. The browser category is treacherous. There are at least two ways to think about a browser: as a metalayer for communication, or as a glorified HTML renderer. Both are true at the same time, which is part of what makes it so hard to position. Today when I describe the products I usually start with "multiplayer browser" and then get specific. "

FigJam or Miro with a browser built in" for Sail, "Slack and a browser as an integrated work environment" for Muddy. Those descriptions are what I gravitated to because they land. But the descriptions that land aren't necessarily the descriptions that lead people to the right behavior. Would people think to use this as a meta layer for work? Or are they just stuck on "oh this is like Miro but with websites, I'll use it for all the things I use Miro for." Or with Muddy, "oh this is a better Slack" (though of course no one wants to position themselves as "better version of X" especially when they are not that much better). We went back and forth on whether we should position ourselves as a browser at all. "A browser that is not a browser." Can we really get away with positioning this as an operating system? That term is so saturated and overloaded and technical. An "all in one workspace," too broad and complicated. How do you explain that you have embedded web contents and that all auth, extensions, and everything else work like a browser, when the UI doesn't always land like that? We weren't alone in this struggle. While we were building Sail, Arc by Browser Company and Mighty were in development too. All of us talked about building a new kind of computer. That framing is great for recruiting and to some extent high level marketing. But there's a gap between what you want people to do, what you want people to say, what people actually say, and what the thing actually is. No matter how ambitious the vision, the market reduces you to a simple description. Mighty × Mighty shut down in 2022. Their retrospective is honest about why: "the benefits of Mighty just weren't substantial enough to handle the drawbacks." Apple's M1 chip ended up matching their cloud server performance, eliminating much of the speed advantage. becomes "fast Chrome on the cloud." Arc × Browser Company pivoted away from Arc to build Dia, an AI browser. Josh Miller's letter to Arc members describes it well: "for most people, Arc was simply too different, with too many new things to learn, for too little reward." Only 5.5% of daily users used more than one Space. They called this the "novelty tax." becomes "pretty browser with a more organized sidebar." Sail becomes "Miro but with websites."