Syncit

The Spark

I was first exposed to the idea of synchronized playback a few years ago by an app called 'Ampme,' which syncs music across multiple phones to amplify the sound. I thought it was a brilliant concept, but I wanted something that worked seamlessly across both my phone and my laptop. At the time, it was just a passing thought.

Later in college, a Google Chrome Extensions development course opened my eyes to the true power and capability of the browser architecture. Soon after, while sitting in class, I was listening to a song and wanted a friend sitting across the room to hear it simultaneously. I realized there should be a way to co-experience media from afar, where anyone in the session could control the playback. That day, the idea for Syncit was born.

First Principles & Early Constraints

At the time, I wasn't even familiar with the industry term "watch together." I started entirely from first principles.

I knew I could inject content scripts into pages to manipulate media elements, but I wasn't sure if major streaming platforms had guardrails against it. To mitigate risk and complexity, I kept the initial architecture dead simple: a single play/pause button on the extension popup, a basic content script targeting the video element, and a clean logo—because branding matters right from the start.

To avoid complex video selection algorithms on media-heavy pages, I made a key design decision: sync the entire browser tab rather than individual video elements. This constraint simplified the logic by restricting the session to one active video per tab. Over the following months, I dialed in the local sync engine. When a user took an action, the content script messaged the background script, which forwarded the event—along with crucial execution timestamps—to the other connected content scripts.

Turning Infrastructure Limits into Features

As a student, I didn't have the budget to host dedicated WebSocket servers for real-time signaling. Instead, I turned to a cloud platform I already knew: Firebase Firestore.

Using a document database as a real-time messaging layer is generally an anti-pattern due to latency and operational costs, but this constraint forced a massive architectural breakthrough. Because Firestore charges per read/write operation, I was highly incentivized to minimize the data packets sent.

To make this work, I designed Syncit's core algorithm to predict where a user is now based on when they sent their last state packet, alongside a custom clock-synchronization system to handle time drift between devices.

// A conceptual look at Syncit's Latency-Compensation Engine
function calculateTargetPosition(packet) {
  const currentSystemTime = Date.now();

  // Calculate the exact time elapsed since the packet was sent
  const networkLatency = currentSystemTime - packet.sentAtTimestamp;

  // If the sender was actively playing, extrapolate where they are 'now'
  if (packet.playerState === 'PLAYING') {
    return packet.videoCurrentTime + (networkLatency / 1000);
  }

  // If they paused, the target position remains static regardless of lag
  return packet.videoCurrentTime;
}

The result? The design smoothly absorbs network delay. Even if a packet arrives seconds late due to a lag spike, the playback snaps perfectly into place. By optimizing for minimal database writes, Syncit inadvertently became incredibly network-resilient, natively handling instability, buffering, and sudden disconnections better than platforms relying on constant WebSocket streams.

The Architectural Evolution: Scaling Smart

While the predictive algorithm made the system incredibly resilient, scaling a pay-per-operation database for a high-frequency synchronization app wasn't a viable long-term strategy as user activity grew.

To optimize production efficiency and align costs with actual app behavior, I migrated the signaling layer to Firebase Realtime Database (RTDB). By moving to a platform that bills based on bandwidth data transfer rather than individual read/write counts, I drastically reduced operational overhead.

Combined with the existing state-prediction logic, Syncit now enjoys the best of both worlds: the ultra-low latency of a dedicated JSON data stream and an architecture that handles network instability natively without ballooning cloud costs.

The Next Frontier

Today, Syncit is incredibly stable and supports synchronized playback across virtually any video platform on the internet. It is exactly what I envisioned back in that college classroom. But the roadmap goes much further.

To build a truly compelling, friction-free ecosystem, I am currently tackling two major focus areas:

• Native Communication Channels: Currently, Syncit assumes users are already on an external platform like Discord or a phone call. I am actively developing integrated text, voice, and video chat to make it a completely self-contained social space.
• Mobile Expansion: Chrome extensions carry high friction and exclude users without laptops. Bringing Syncit to mobile platforms will allow friends to hang out, share content, and react natively from any device.

The ultimate goal for Syncit is to become a living social layer over the web—turning co-watching into a casual, habitual way to hang out with friends online.