4 ms·

Hi maxwell, what would you recommend to another developer who might be entering the same space with a WebRTC-based product?

maxwell 7y ago
We settled on TokBox. We were one of their first customers making significant use of server-side recording (virtual estimates for home service providers), and worked closely with the TokBox QA/dev team to resolve bugs until things stabilized in 2016 around the time we hit real product-market fit (focusing on relocation moving estimates). I've stepped away but AFAIK they're still using it. It was expensive but worked with our business model ($20 for a successfully completed self-service video call between service provider and end customer, $50 to have the virtual survey performed/recorded by our trained video surveyors around the world, $90 to also have priced). I'd compare TokBox, Twilio Video, and Jitsi.
- forkLding 7y ago
  Thanks maxwell for the answer! Really appreciate it, apologies for asking more but how did you guys handle customer browsers not really up to date or compatible with webrtc back then?
  - maxwell 7y ago
    We initially handled browser-specific bugs in an ad hoc manner, and kept hitting unexpected issues with slight variations in hardware and software. The most common issue was that things failed in a way we weren't expecting and the solution was better error handling. The usual tools for cross-device/browser testing (e.g. BrowserStack) didn't work for video chat: we could simulate network disruptions but needed actual hardware for testing and debugging video/audio issues. So we bought/pooled a ton of devices and had a QA team in our European office methodically test across devices and browsers. We were also contending with provider (TokBox) issues early on in '15, which were mostly resolved by mid '16. Our business model, and pivots that focused our target market, didn't enable building out that level of infrastructure in-house, and I wouldn't recommend it if making any kind of vertical play, i.e. unless your customers are developers.

maxwell 7y ago

We settled on TokBox. We were one of their first customers making significant use of server-side recording (virtual estimates for home service providers), and worked closely with the TokBox QA/dev team to resolve bugs until things stabilized in 2016 around the time we hit real product-market fit (focusing on relocation moving estimates). I've stepped away but AFAIK they're still using it. It was expensive but worked with our business model ($20 for a successfully completed self-service video call between service provider and end customer, $50 to have the virtual survey performed/recorded by our trained video surveyors around the world, $90 to also have priced). I'd compare TokBox, Twilio Video, and Jitsi.

forkLding 7y ago
Thanks maxwell for the answer! Really appreciate it, apologies for asking more but how did you guys handle customer browsers not really up to date or compatible with webrtc back then?
- maxwell 7y ago
  We initially handled browser-specific bugs in an ad hoc manner, and kept hitting unexpected issues with slight variations in hardware and software. The most common issue was that things failed in a way we weren't expecting and the solution was better error handling. The usual tools for cross-device/browser testing (e.g. BrowserStack) didn't work for video chat: we could simulate network disruptions but needed actual hardware for testing and debugging video/audio issues. So we bought/pooled a ton of devices and had a QA team in our European office methodically test across devices and browsers. We were also contending with provider (TokBox) issues early on in '15, which were mostly resolved by mid '16. Our business model, and pivots that focused our target market, didn't enable building out that level of infrastructure in-house, and I wouldn't recommend it if making any kind of vertical play, i.e. unless your customers are developers.