Android devs are guessing at compliance forms. Here's a tool that reads the APK and tells them what to disclose.
There's a Reddit thread in r/androiddev where someone asked how to fill out the Google Play Data Safety form correctly. Sixty-three upvotes, 51 comments. The top responses: 'I just guessed,' 'spent 3 hours on this,' 'genuinely have no idea what Crashlytics collects.' One person got a warning from Google for an incomplete form.
That thread is your product brief.
The pain is real and specific. Android devs using Firebase, AdMob, Crashlytics, and a handful of analytics SDKs have to manually map what each one collects to a form with specific categories like 'location data,' 'financial info,' 'app activity.' Google's SDK Index has this information, but it's spread across 500+ individual pages. Nobody is aggregating it. Nobody is connecting it to what's actually in your APK.
That's the gap. And it's achievable to build.
Forget CI plugins and team seats for now. The MVP is this: paste your `build.gradle` dependencies, get back a pre-filled Data Safety form with evidence lines per SDK.
That's it. A Python microservice that parses the dependency list, looks up each SDK in a curated database you've built, and returns form-field suggestions with citations. Wrap it in a Next.js frontend with a Supabase backend for storing results, and you have something you can put in front of real users within a week.
The apktool/aapt2 APK parsing comes later. Start with Gradle paste because it's faster to build, covers 80% of the use case, and you can validate demand before touching native binary analysis.
The SDK mapping database is the actual product. You need maybe 30-50 SDKs to cover 90% of what indie devs use: Firebase Auth, Firestore, Analytics, Crashlytics, AdMob, Adjust, Branch, AppsFlyer, OneSignal, Amplitude. Build this manually first. Copy from Google's SDK Index, cross-reference each SDK's privacy policy, map to Play Data Safety categories. It'll take two days. That's fine. That's the moat you're starting to build.
For SDKs not in your database, use an LLM prompted on Google's Data Safety documentation to generate a suggested mapping with a confidence score. Flag anything under 80% confidence for human review. This is exactly where AI actually helps rather than being a liability.
Post in r/androiddev: 'I built a free tool that tells you exactly what your Firebase/AdMob stack needs to disclose on Play. Paste your dependencies.gradle and get your form answers.'
Don't ship anything. Collect emails via Typeform. Manually analyze the first 20 submissions using Google's SDK Index. Send personalized PDF reports by hand within 24 hours.
If you get 20 signups in 72 hours and at least 5 people respond positively when you DM them a $29/month offer, you have a signal worth building for. If you get 3 signups, you've saved yourself 5 weeks.
The manual approach also teaches you things no amount of code will. You'll see which SDKs people actually use. You'll see which form fields confuse them most. You'll learn where the legitimate ambiguity is versus where people are just lazy. That knowledge makes the product 10x better.
Next.js for the frontend. Supabase for auth, database, and storage. Stripe for payments. Python microservice (FastAPI) for the APK parsing using apktool and aapt2 wrappers. The Python service runs as a separate process you call via API. Don't try to do binary analysis in Node.
With Cursor or Lovable, the Next.js frontend and Supabase integration is a weekend. The Python parser takes longer because APK analysis has edge cases, but the Gradle paste version is maybe a day of work. Get the web UI working first, make money, then improve the analysis.
Free tier: one scan per month, watermarked report. Make the watermark annoying. $29/month Solo gets unlimited scans and full PDF reports. $79/month Team gets the CI/CD plugin, three seats, and Slack notifications.
The free tier is acquisition, not a product. Be aggressive about capping it.
At 18 Solo customers you're covering infrastructure. At 35 you're replacing a $50K salary. The unit economics work because the gross margin is around 88%. Your main cost is compute for APK parsing, which is minimal at indie scale.
One thing to watch: churn will be brutal on Solo. Devs subscribe, scan their app, leave. Monthly churn of 15-25% is realistic in year one. The LTV math only works if you're actively pushing people toward the Team tier. Watch for users who hit the free scan cap multiple times and reach out directly.
Two things could kill this fast.
First: Google ships a 'verify with Android Studio' wizard that does this natively. They have the SDK Index database internally. They have the Play Console. This is not a far-fetched scenario. The runway is maybe 12-18 months before someone at Google puts this on a roadmap. If you're building this, you need to move fast and start expanding cross-platform to iOS Privacy Nutrition Labels and GDPR records of processing before that happens. The CI audit trail has value that survives even if Google adds basic form hints.
Second: if your tool auto-fills a form incorrectly and a developer gets their account suspended, that's a legal problem. Not a theoretical one. App removal and account termination are real outcomes of inaccurate Data Safety forms. Your disclaimers will help but won't fully protect you. The right response is building the human-review checklist into the product from day one. Never present output as 'done.' Present it as 'suggested, review before submitting.' Every report should have a page of flagged ambiguities. This isn't just legal cover, it's actually more useful than false confidence.
Also worth knowing: MobSF is open-source and already does 90% of the underlying APK analysis. Once you get traction, someone in that community might build a Play Data Safety export module. The window where you have a commercial advantage is finite.
R/androiddev has 850K members. Android Weekly newsletter has 50K+ subscribers. These are zero-CAC channels if you post something genuinely useful rather than a pitch.
The Loom demo approach works well here. Record yourself uploading a real Firebase app and watching the Data Safety form fill itself in 60 seconds. No narration trying to sell anything. Just the tool working. Post it with 'built this for myself, happy to run it on your APK free.' That's the kind of thing that gets traction in developer communities because it respects people's time.
DM the most upvoted commenters from that original Reddit thread. They already told you they have this problem. They're your first customers.
Weekend one: SDK mapping database for top 30 SDKs, Gradle paste parser in Python, basic Next.js UI that returns form field suggestions. This is your validation tool, not your product.
If validation works: weeks 1-2 expand the SDK database and APK parsing. Weeks 3-4 web UI and PDF report generation. Week 5 Stripe integration. Weeks 6-7 CI plugin and QA.
The CI plugin is a GitHub Action that runs on every PR and comments when new data-collecting SDKs appear. It's maybe 3 days of work and it's what transforms this from a one-time scan into something teams depend on every day.
The 'aha moment' you're building toward is a developer uploading their app and seeing their Firebase+AdMob Data Safety form pre-filled in under 60 seconds with exact evidence lines they never had to look up. That moment is real and specific and achievable. Everything else is in service of getting someone there.