Adaptive video session proxy for low-bandwidth classrooms

A teacher in a rural school or a university trainer schedules a live video session, half the participants join on weak Wi-Fi or mobile data, and by the fifteen-minute mark half the class is frozen or dropped. The teacher has no visibility into who is struggling — they just see people go silent. That's the moment this solves.

The gap persists because video conferencing vendors are structurally incentivised to deliver the richest possible experience to the majority of users on good connections. Building aggressive adaptive degradation that serves the tail of the bandwidth distribution makes their product look 'low quality' in marketing comparisons. So they set a floor — run our speed test first, meet the minimum — and wash their hands of everyone below it. There's no lobby of poor-connection users complaining loudly at an enterprise procurement meeting.

What's actually missing is a middle layer that transcodes and proxies video streams in real time: participants with weak connections receive a reduced-resolution, audio-prioritised stream while others get full quality, without the host doing anything. Existing workarounds — turning off cameras, using audio-only mode — are manual, social, and awkward. They require participants to self-identify as the 'slow' person in the room. The complaints are consistent: 'consumes lots of data and performance degrades significantly with a moderate connection.' Nobody built the automatic fix because it sits awkwardly between the conferencing vendor (who doesn't want to own it) and the network provider (who doesn't touch application layer).

For an edtech company running live online courses, a session where 30% of students can't participate isn't a minor inconvenience — it's a refund request, a support ticket, and a churn signal. The cost is concrete and recurs every single class. A proxy service that automatically serves each participant at the bitrate their connection can handle, without requiring them to install anything beyond the normal join link, is a business because every new cohort, every new geography they expand into, brings the same problem back.

What to build

Build a WebRTC-compatible transcoding proxy that joins a video session as a relay node, detects each participant's available bandwidth on connection, and serves them a dynamically adjusted stream — dropping to audio-plus-thumbnail at low bandwidth — while the host's session continues unmodified.

Where to start

Start with edtech companies that run cohort-based courses in Sub-Saharan Africa or Southeast Asia, where the bandwidth problem is acute enough that they're already losing money to refunds and dropout — they'll pay specifically for geographic reach, not general quality improvement.

The hard part

WebRTC transcoding at scale requires significant compute infrastructure per session, making unit economics brutal at low session volumes — you need high-frequency, predictable session loads from day one to avoid burning cash on standby capacity.

How it makes money

Charge per participant-minute of relayed bandwidth consumed, with a monthly minimum that covers baseline infrastructure; expansion pricing kicks in as customers add new geographic markets.