Tool that reveals what third-party SDKs in your app are phoning home
Problem
App developers ship products packed with third-party dependencies but have no visibility into what those SDKs actually send off-device: most have no idea what their own dependencies transmit. Network-level tools exist, but app-level visibility into which SDK emitted which request, with which data, is missing.
Opportunity
A developer tool that instruments an app's network layer and maps every outbound request back to the specific third-party SDK that made it, surfacing hidden telemetry, PII leaks and unexpected data collection before it reaches production or an app-store review.
Market analysis
Authentic developer pain with a clear technical wedge (request-to-SDK attribution at app level), but the space around it is filled by free OSS debug monitors and privacy scanners. The defensible product is a compliance/CI angle, not another network inspector.
Market · Mobile app developers and security/privacy-conscious teams; demand signaled directly on Ask HN and by the growing difficulty of app-store privacy audits.
Pricing · Adjacent OSS tools are free (FLEX, Netfox, network monitors); dynamic privacy scanning is typically an enterprise B2B line item. Realistic monetization is a CI/privacy-report subscription rather than per-seat debugging.
Pros
- + Pain is articulated first-hand by developers, not inferred.
- + The specific wedge, mapping requests to the SDK binary that emitted them, is genuinely not what Charles/Proxyman do.
- + Natural CI hook: catch PII leaks before an app-store review or release.
Cons
- − Free OSS alternatives (in-app network monitors, proxies, static tracker scanners) cover most adjacent needs.
- − Attribution is technically hard: SDKs often share the app's networking stack, and obfuscation breaks naive call-site mapping.
- − Niche developer tooling with unclear willingness to pay outside enterprise compliance budgets.
Existing / similar tools
Source
Hacker News (Ask HN)
The wedge is attribution, not interception: the value lies in mapping an outbound request to the SDK binary or call-site that produced it, which network proxies structurally cannot do. That mapping is the hard part, because many SDKs share the app’s URLSession or OkHttp stack, so reliable attribution needs swizzling or symbolication and breaks under obfuscation. Monetization only works as a compliance product, an automated “what did we just ship” report wired into CI, since pure debugging will always be compared against free tools. Without that compliance angle this stays a great open-source project rather than a business.