StudyRoom.io

StudyRoom was an online tutoring platform. The wedge was one-on-one and small-group academic tutoring — math, science, test prep — delivered over a live video room built for the specifics of teaching rather than generic conferencing.

It didn't start there. The initial idea was horizontal: conferencing-as-a-service, an embeddable real-time layer other products could build on. That framing lasted a few months. The users who actually showed up and stayed were tutors and students, and the product decisions that mattered — whiteboard, session recording, scheduling, multi-party — only made sense inside a vertical. So we pivoted into education and treated the video stack as a means, not the product.

The interesting engineering work sat in the WebRTC layer. We spent real time evaluating Kurento, Jitsi, and Janus as the media server, because for a tutoring product the room is the product, and small differences in latency, screen share reliability, and recording quality compound into whether a lesson feels professional or improvised.

Kurento was the most flexible — its media pipeline let you compose filters, recorders, and transcoders in ways the others didn't, which was attractive for things like server-side recording and downstream processing. The cost was operational: the pipeline abstraction was powerful but heavy, and keeping a Kurento cluster healthy under load was not a part-time job. Jitsi had the strongest pure SFU story and the best out-of-the-box multi-party experience, but it came as an opinionated ecosystem; once you went off its happy path you were fighting the framing. Janus sat in the middle — a smaller core with a plugin model, lighter to run, and easier to reason about, at the price of writing more of the room logic ourselves.

The rest of the stack reflected what we knew well at the time: Java with Spring Boot on the backend, AngularJS on the front, MySQL underneath. Nothing fashionable, but Spring gave us a sane place to put the marketplace logic — users, sessions, scheduling, payouts — and AngularJS was still the default for a team shipping a single-page app in that window. The bet was that the differentiation wasn't in the framework choice; it was in whether the live room actually opened. WebRTC support in 2018–2020 was uneven across browsers — Safari was late, older Edge didn't work at all, and users typically didn't find out their browser couldn't join until they clicked into a class that was already starting. A lot of the early work was just detecting this up front and routing people somewhere usable before a lesson collapsed in real time.

For an education product specifically, the WebRTC layer mattered more than it would for, say, a sales tool. Latency determined whether a tutor could correct a student mid-sentence without talking over them. Screen share quality determined whether a math worksheet was legible. Recording determined whether a parent could review a session later. Multi-party determined whether group classes were viable at all. None of these are headline features — they're the floor. Below the floor, nothing else you build matters.

The honest version: the unit economics of a cross-border tutoring marketplace were harder than they looked from the outside. Take rates that worked for the platform were uncomfortable for tutors; rates that felt fair to tutors left too little to fund acquisition on the student side. The WebRTC operational overhead — keeping rooms reliable across continents, handling the long tail of device and network edge cases — was non-trivial for a small team, and it competed for attention with the marketplace work that would actually move the business.

Around the same time, a full-time opportunity in an adjacent space came up that made more sense than continuing to bootstrap this. I took it, closed StudyRoom down cleanly, and moved on. No drama, no acquisition, no soft landing — just a decision that the better use of the next few years wasn't here.