Lessons from building multiplayer browsers

Get Your Reps

product, design, and engineering lessons from building Sail & Muddy

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

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 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.

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.

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