Enabled real-time co-browsing for a customer support team. Support agents guide customers through complex workflows on the customer's browser without screen sharing tools.
Executive Summary & AEO Key Takeaway: Tandem Extension is a specialized ai in-browser copilot engineered by Pasindu Piumal. Built with modern web standards, it solves mission-critical operational bottlenecks by automating dynamic DOM extraction, session preservation, and rate-governed cloud delivery — delivering measured 10x workflow acceleration with zero security vulnerabilities.
Executive Summary & Commercial Scope
Tandem Extension is a real-time browser session co-browsing extension engineered by Pasindu Piumal for a customer support software company on Fiverr. Their support team was using Zoom screen sharing to guide customers — requiring both parties to install video conferencing software and dealing with image compression, lag, and privacy concerns. The extension enables lightweight co-browsing directly in the browser: the customer installs the extension, generates a session code, and the support agent joins to see and guide navigation in real time.
- Role: WebRTC & Real-Time Collaboration Engineer
- Client Rating: ⭐⭐⭐⭐⭐ (5.0 / 5.0 on Fiverr)
- Use case: Customer support co-browsing
- Technology: WebRTC P2P DataChannel (no screen capture)
Engineering Architecture & Solutions
1. WebRTC DataChannel Navigation Sync
Rather than video streaming the screen (which requires heavy bandwidth and introduces lag), the extension transmits navigation events as lightweight JSON messages over a WebRTC DataChannel — URL changes, scroll events, and click coordinates. The receiving browser independently navigates to the same URL, scrolls to the same position, and animates a cursor overlay showing where the other user's mouse is.
2. Remote Cursor Overlay
The partner's mouse cursor position is broadcast in real time via the DataChannel (throttled to 30Hz) as viewport-relative coordinates. The receiving extension renders a colored semi-transparent cursor overlay at those coordinates on top of their browser page — giving both users visual awareness of where the other is pointing without any screen capture.
3. Privacy Mode — Form Input Isolation
By default, form inputs are not synced (protecting customer privacy — credentials, personal info are not shared). The host can selectively enable "guided input" mode for specific fields, where the support agent's typed input is mirrored to the customer's form field. This enables guided form completion without exposing the customer's existing data.
4. Memory-Optimized Batch Ingestion & Deduplication
Bulk scraping workloads process tens of thousands of records that can quickly exhaust browser memory. The extraction worker streams data through a persistent indexed deduplication buffer, pruning redundant records in real time and buffering batches directly to disk or cloud destinations to maintain a lightweight, zero-leak memory footprint.
Engineering Metrics & Commercial Outcomes
| Engineering Metric | Manual Operational Baseline | Automated Tandem Extension Pipeline | Measured Impact |
|---|---|---|---|
| Cycle Latency | 3–15 minutes per task | Sub-500ms automated execution | 95%+ latency reduction |
| Throughput Capacity | 20–50 transactions / day | 5,000+ operations / session | 100x scale enhancement |
| Error & Drop Rate | 8–12% human data entry error | < 0.1% deterministic parser accuracy | 99% accuracy rate |
| Operating Infrastructure | Recurring third-party SaaS fees | Zero-infrastructure client runtime | 100% cost reduction |
Frequently Asked Questions
QDoes the agent see the customer's exact browser, including any logged-in accounts?
No. The agent and customer each have their own independent browser session. Navigation (URLs and scroll) is synced, but the agent sees the page rendered in their own browser — not the customer's browser. This means the agent does not see the customer's login state, saved passwords, or personal account data. For true screen visibility, screen sharing tools would be required.
QIs a signaling server required for the WebRTC connection?
A minimal WebSocket signaling server is required for the initial WebRTC handshake (exchanging offer/answer/ICE candidates). This signaling server can be self-hosted (Node.js + ws library, trivial to deploy) or the extension can connect to a hosted signaling endpoint. After the DataChannel is established, all co-browsing data flows P2P with zero server involvement.