Tech: Frontend uses Svelte / Snowpack, which is great. The game view uses the DOM, which is questionable, but my webgl implementation wasn't so hot either.
Backend is Firebase for general stuff, server written in Golang for the realtime game stuff, and another Golang server for video.
Main techincal lesson learned so far: WebRTC sure is a pain to get right across everyone's devices, browsers, and connections.
The good news is that the browser/device/connections issues have gotten so, so much better! All the browsers now mostly agree on aiming towards full compliance with the WebRTC 1.0 spec. The likelihood of something important breaking in a browser release is trending downwards. And the encoding -> network -> decoding pipelines in libwebrtc are pretty robust and performant these days.
But, as someone who has been doing WebRTC stuff since 2014 or so, and started a company that's in part a bet on the WebRTC ecosystem, I have a lot of scars from how long it took to get here. :-)
I'm biased, but I would say that there are still three classes of non-trivial difficulty that add up to "you shouldn't build everything yourself" being the right answer if you're building WebRTC-reliant features that you want to deploy to production:
1. cross-device issues are still painful and still a moving target
2. network bandwidth and track/encoding configurations for any use cases more complex than 1:1 calls are a steep learning curve plus lots of corner cases
3. devops as you scale usage is a lot of work because there aren't any off the shelf cloud provider things you can just turn on and expect to work