What that meant for us is we decided to focus specifically on burst data. As a result our hardware can be lighter/smaller/less expensive and our networking protocols can scale to do things that other mesh projects have failed at.
For goTenna/goTenna Mesh, not doing real-time high-bandwidth media transmissions is a feature not a bug. Plus, focusing on packetized burst data transmissions doesn't preclude us from even sending a whole Netflix show over goTenna if we wanted to, because you could technically send a video over in lots of small packets and reconstruct it at the other end. Everything, after all, are 1's and 0's. (BTW with our SDK you can do that if you'd like! We're still gonna be focused on text & GPS in our own apps for now - for both goTenna v1 and goTenna Mesh).
Because we didn't have the choice of working on beautiful licensed spectrum used by limited users and less subject to regulations by government. We always had to by definition design goTenna (and now goTenna Mesh) to work on public spectrum which is a scarce and shared resource with potentially unlimited users and regulations that we have to fit into.
TL;DR: Focusing on burst data has been a really great way of scaling our technology from the first intelligent protocols that power v1 (which we call Aspen Prime) and goTenna Mesh (Aspen Grove).
Also perseverance. And naivete probably helped too because it's easier to get into something difficult when you have no clue how hard it's gonna be. We've learned a lot along the way since our first working prototypes in early 2013.
(Sorry if I sound barely coherent right now; I haven't slept in a few days leading up to goTenna Mesh launch!)