Collaborative Screen Sharing — you each get your own mouse, and…
Explore the risks and possibilities with a prompt for ChatGPT, Claude, or your agent.
Screenhero was a collaborative screen-control product founded by Jahanzeb Sherwani, Vishal Kapur, Jason DiCioccio, and Faraz Khan before its February 2013 launch and accepted into Y Combinator's Winter 2013 batch. It let two people control the same Mac or Windows desktop with independent cursors and keyboards, making remote pair work feel closer to sharing one machine.[1]
Slack acquired Screenhero on January 28, 2015 in an undisclosed cash-and-stock deal. All six employees joined Slack to build voice, video, and screen-sharing capabilities. Screenhero remained available during integration, then shut down on December 4, 2017 after interactive control appeared in Slack.
This is both an acquisition success and a standalone-service shutdown. The team and product behavior influenced Slack Calls and interactive sharing, but public evidence does not establish direct code reuse. Current Slack Huddles retains screen sharing and drawing, not the full dual-cursor remote-control model.
YC identifies Sherwani as founder and CEO, Kapur as founder and CTO, and DiCioccio and Khan as founders. Secondary company data says the four had previously built iTeleport, a remote-desktop product for iOS and Mac, but the packet does not provide a primary origin record or complete role history.[2]
The exact incorporation and founding dates were not found. The public evidence establishes that the company existed before its February 2013 launch, but not the year it was founded.
The founding insight was behavioral. Existing screen-sharing tools such as WebEx and GoToMeeting emphasized presentation. Remote developers and help-desk workers needed responsive co-control. Screenhero let each participant move a separate pointer and type into any desktop application, an interaction YC described as Google Docs-style collaboration for the entire desktop.[3]

Remote pair programming became the largest use case. Sherwani later wrote: “The main reason why Screenhero was loved was because it was fast.”[4] Responsiveness mattered because small delays break conversational turn-taking and make shared control feel like remote support rather than collaboration.
Screenhero supported Mac and Windows, integrated HD voice, and reported that 92 percent of sessions were peer-to-peer encrypted. It said remaining sessions were encrypted and not trackable by Screenhero, though the packet contains no security audit, relay design, or key-handling details.
No second origin-era founder quote surfaced. The team's later “We’ve finally done it” statement belongs to the Slack integration and closure, not the founding period.

Screenhero shared any Mac or Windows application while giving both participants an independent mouse pointer and keyboard input. Unlike presentation-first conferencing, both people could act inside the same development environment, design tool, browser, or support workflow.
The product combined low-latency screen sharing, multi-mouse control, and voice. TechCrunch's hands-on review reported little lag but did not provide measurements. Sherwani's later 30 to 50 millisecond figures concerned a subsequent product, not Screenhero, so they should not be back-applied.
The control semantics were the differentiator. Two cursors made ownership visible. Shared keyboard input let a remote collaborator write or edit directly. This was especially useful for pair programming, where participants need to switch roles quickly rather than request control through a support-style handoff.
At acquisition, Screenhero's customers included SendGrid, New Relic, GitHub, LivingSocial, and Automattic. Developers and help-desk workers were important customer groups.[7] WIRED described the central behavior as two people simultaneously entering text and moving objects within one shared desktop application.[8]
Slack integrated the capabilities in stages: voice calling, video calling, presentational sharing, then interactive control. The October 2017 release let participants share control, edit, troubleshoot, and draw temporarily over a screen. Slack supported up to 15 participants, expanding beyond Screenhero's two-person design.

The Screenhero team still listed speed, command or alt-tab support, and remote copy and paste as unfinished priorities. That gap is evidence of behavior-level lineage rather than perfect feature parity.
Screenhero competed with WebEx, GoToMeeting, TeamViewer-style remote access, and document-specific collaboration. Its narrow position was highly responsive shared control across arbitrary desktop applications. It did not try to become a broad messaging or meeting suite.
That focus appealed to technical teams. Pair programmers valued rapid role switching; support teams could diagnose and act together. Butterfield said: “The cursor control that Screenhero offers, we hadn’t seen anything like that before.”
The product's limitation was platform dependence. Screen capture, input injection, window behavior, keyboard shortcuts, clipboard semantics, codecs, networking, and operating-system security all affect the experience. No Linux version shipped before acquisition. Accessibility and internationalization were not researched.
Slack offered distribution and a larger collaboration context. It also imposed architectural constraints. Sherwani later said Screenhero predated Electron and that Slack's unmodified Electron requirement made equivalent latency improvements impractical for a relatively small feature. That is first-person retrospective evidence, not an independent architecture review.
Current Slack Huddles supports video, up to two simultaneous screen sharers, collaborative drawing, and larger participant counts.[9] It does not document taking remote mouse or keyboard control. The original dual-cursor experience therefore did not survive intact.
Historical Slack changelogs confirm screen-control sharing launched in October 2017 for co-editing, clicking, drawing, and navigation.[10] This supports product influence but not continuous current availability or code-level survival.
Screenhero priced from $11 per user monthly to $444 monthly for 50 users. Slack saw voice and screen control as a possible paid feature and an entry into customer support. No customer count, seat count, session volume, retention, margin, burn, or verified annual recurring revenue was found.
Dealroom reports $125,000 of YC funding, a $1.8 million round, $2.6 million total financing, and a rapid $1 million ARR milestone. Its funding table conflicts with its narrative, and no primary financing or financial record verifies those claims.
The Slack consideration included cash and stock, but neither amount nor allocation was disclosed. A Czech report estimated $15 million to $25 million and repeated the $2.6 million funding figure, but both are unverified estimates.[11] No acquisition agreement, founder proceeds, retention grants, earnout, or ownership data was found.
Named customers included well-known software and internet companies. All six employees joined Slack, taking Slack just above 100 people at announcement. Sherwani said the company was under no pressure to sell and that growing internal use of Slack made the combination natural.
No registered-user count, paid seats, teams, sessions, retention, or audited revenue was found. Named customers and acquisition interest demonstrate strategic use, not business scale.
Slack acquired Screenhero deliberately, retained the entire team, and promised to integrate the product. Screenhero stayed available temporarily before shutdown. There is no evidence that commercial failure forced the sale.
The standalone product fully closed at 11 a.m. Pacific on December 4, 2017. Non-paying users received a 60-day Slack trial. The service shutdown was real even though behavior appeared inside Slack.

The team wrote: “We’ve finally done it: Screenhero-style screen sharing is now in Slack!”[12] TechCrunch described the release as enabling markup, editing, scrolling, and work on shared projects.[13]
Yet the team listed missing speed and input behaviors. Sherwani later said interactive sharing was eventually sunset. Current Huddles documentation lacks remote control. Technical influence and temporary behavior survival are well supported; uninterrupted feature or code survival is not.
The non-obvious mechanism is semantic loss. A roadmap can say “screen sharing shipped” while omitting the exact interaction that users valued: two visible cursors, shared input, responsiveness, keyboard semantics, and remote clipboard behavior. Feature names are too coarse to prove continuity.
The rebuild opportunity is a metadata-only lineage receipt connecting source behavior, performance targets, input semantics, operating-system dependencies, security and accessibility constraints, integration targets, tests, notices, fallback, deprecation, and corrective actions.