Thanks for all the great questions! The overhead is fairly minimal since we mostly intercept things that happen in the app and don't really have any things tha

Thanks for all the great questions! The overhead is fairly minimal since we mostly intercept things that happen in the app and don't really have any things that run continuously at high frequency, e.g. we add about 0.5ms to network calls on average devices. The RAM usage is limited since we put caps on how much data we capture in a session. We do give devs the option to configure the SDK to capture screenshots when errors occur, which is the largest consumption of RAM we incur, but that can be disabled. We make network calls for logs and submitting session data, so that does some bandwidth, but as mentioned above we put caps on how much data we capture in a session to avoid payloads getting excessively large. We've had some customers who have been pretty sensitive to battery drain, and from working with them we've solved a couple of issues that did affect battery drainage, but no longer do. We haven't invested a ton of effort yet to optimize the SDK specifically for 2G environments. That said we do have customers using our service with large user bases in India and the Philippines, where many of their users are on less-than-stellar network connections. As we expand to serve more markets where 2G is more common, we will be focusing on SDK performance for that. As to how we ensured the SDK wasn't causing problems.... blood, sweat, and tears? Jokes aside, we had great early adopters who worked through some painful bugs with us. We've also had some devs at companies that we think have high code standards give us pointed feedback. Our basic thesis is that development for mobile is hard, and developing an SDK for mobile that does not impact the app it's integrated in is really hard, so we also used our own tool to figure out when things were not going right with the SDK. The backend stack uses a bunch of wonderful OSS tech like nginx, Kafka, Cassandra, Clickhouse, Redis, MySQL, React, Gin, and Django. We are dealing with data volumes that pose fun engineering challenges, and we wouldn't be able to do it if we weren't standing on the shoulders of giants. If I missed the mark or you're looking for more depth, don't hesitate to follow up!