Hyperbeam Puts a Shared Browser Inside Your App

There is a small, stubborn problem on the web that most people never notice until they need it: it is surprisingly hard to let two people use the same browser at the same time. Not two copies of the same page - the same live browser, where one person clicks a link and the other person sees it happen instantly. For years, if you wanted that inside your product, you built it yourself, badly, and then maintained it forever.

Hyperbeam is a company that decided to make that the easy part. Its product is an API. You call it, and it hands back a virtual computer running in the cloud - a full Chromium browser on a remote server - that you can drop into your web app, mobile app, VR headset, or even a VSCode panel. Multiple people can watch it, control it, and talk over it at the same time. The pitch, stripped of jargon, is this: embed a real browser anywhere, and let a crowd share it.

01 / The OriginAn app for watching movies together

Before Hyperbeam was infrastructure, it was a hangout. Around 2020, co-founders Philip Scott, Ambareesh Balaji, and Declan Goncalves - all engineers out of the University of Waterloo, with stints at Facebook, Yahoo, and Lyft between them - built a consumer app at hyperbeam.com. The idea was simple and of its moment: browse the web and watch things together with friends, in sync, from anywhere. It worked. The app climbed to roughly 150,000 monthly active users.

And then it stopped climbing. Growth flattened. This is the part of the story most founders find hardest, because a plateau at 150k users is not a failure you can easily walk away from - it is big enough to feel like something and small enough to feel like nothing. A consumer product that has stalled will happily absorb another year of feature work and marketing experiments, and often the honest thing to do is the least comfortable: to admit the ceiling is real and go looking for a different door.

The team's background matters here. Scott, Balaji, and Goncalves were engineers before they were founders, with time at companies like Facebook, Yahoo, and Lyft between them. That kind of resume tends to produce people who are more interested in the machine than the marketing around it. When the app plateaued, they had the instinct to ask a builder's question rather than a growth-hacker's one: not "how do we squeeze more users out of this," but "what is the most valuable thing we've actually made here?"

02 / The PivotKeep the engine, sell the engine

After getting into Y Combinator's Winter 2022 batch, the team looked harder at what they had actually built. The watch-party app was one use of the technology. But the technology itself - a browser running in the cloud that many people could control at once - kept getting requested for other things entirely. Teachers wanted it for remote classrooms. Companies wanted it for virtual offices. Developers just wanted the shared browser, without the consumer wrapper around it.

So they inverted the business. Instead of an app that used the engine, they sold the engine. Within the first two weeks of the pivot, they closed three deals. That is usually the market's way of telling you it has been waiting. A consumer app has to earn each user one at a time; an infrastructure product earns a whole category of builders at once, because every developer who integrates it brings their own users along for free.

The shift also changed who they had to please. In the watch-party days, the customer was a person deciding how to spend a Friday night. As an API company, the customer became a developer deciding what to build on. Developers are a demanding audience - they read the docs, they test the free tier at 1 a.m., they notice when latency is bad - but they are also loyal in a way consumers rarely are. Win the integration once, and you tend to keep it.

03 / The TrickWhy the browser lives in the cloud

The clever bit is where the browser runs. In Hyperbeam, Chromium executes on a server, not on your device, and the result is streamed back to you as video over WebRTC. That design choice has a few pleasant consequences. Because nothing is happening locally, files never have to upload from any one person's machine - there is no upload bottleneck to choke a session. Because everyone is looking at the same streamed instance, syncing audio and video across participants is the default, not a feature you bolt on. And because the heavy lifting sits on the server, the same session can scale to a large number of concurrent viewers.

For a developer, all of that hides behind a REST API and an NPM package. You get programmatic navigation, custom authentication, session persistence, and permission controls - the knobs you need to make a shared browser behave like part of your product rather than a foreign object inside it. Session persistence means a browser can be paused and returned to; permission controls decide who in a room can drive and who can only watch. These are the unglamorous details that separate a demo from something you can put in front of real users.

There is a quiet elegance to running the browser in the cloud rather than the device: it makes the client thin. A phone, a laptop, and a VR headset are wildly different machines, but they can all play a video stream. By pushing the hard computation to the server and shipping only pixels and input events, Hyperbeam turns "which devices do you support" from an engineering project into a non-question. That is why the same session can appear on the web, on mobile, in a headset, or even inside a code editor.

04 / The CustomersWho actually uses a shared browser

The answer turned out to be: more people than the founders first guessed. Because the primitive - a live browser many people can share - is generic, it shows up in a spread of industries that do not obviously belong together.

More recently, a new customer arrived without being asked: AI agents. As "computer-use" models learned to click around the web on their own, they needed a real, sandboxed browser to do it in - exactly the thing Hyperbeam had spent years making embeddable and controllable. A market that did not exist when the company started drifted toward the infrastructure it had already built. The overlap is almost too neat: an agent driving a cloud browser is not so different from a person driving one, and a session a human can watch is a session a developer can debug.

What ties all of these uses together is a single primitive. Hyperbeam does not really sell "watch parties" or "classrooms" or "agent sandboxes." It sells one thing - a live browser in the cloud that more than one actor can control - and lets its customers decide what that thing becomes. The generality is the product. It is also the reason the customer list keeps surprising the founders.

EMBEDDED SESSION // MANY CURSORS, ONE BROWSER

05 / The BusinessPriced like Twilio, not like software

Hyperbeam sells itself the way communications platforms do. There is a free tier - 10,000 minutes a month, no credit card - designed to get a developer from curious to building without a sales call. After that it is pay-as-you-go on session and participant time, with volume discounts that kick in automatically and custom plans for the heaviest users. It is the CPaaS model that Twilio and Agora made familiar: meter the usage, keep the on-ramp free.

06 / The PositionThe layer nobody sees

The most useful way to place Hyperbeam in the market is to compare it to the plumbing companies. Video calls got Twilio. Payments got Stripe. Shared, controllable browsers got Hyperbeam. It sits in the same neighborhood as cloud and remote browser providers - Hyperbrowser, Browserbase, Browserless, Kasm and others - but its lineage is collaboration first, automation second, which shows in how much it cares about many humans in one session, not just one agent in one tab.

That also means it is mostly invisible. If you have joined a watch party, sat in a browser-based classroom, or used a co-browsing support session, there is a chance Hyperbeam was underneath and you never saw its name. For an infrastructure company, that anonymity is not a bug. It is the whole job.

What remains striking about the company is the shape of its story. A consumer app that worked, plateaued, and got quietly retired. An engine that outlived the product it was built for. And a small team that had the discipline to notice their side effect was the actual business, then follow the demand somewhere less glamorous but far more durable.