What shipping AI-built Android apps taught me about Google Play review (and the check I now run first)

A solo developer who builds small Android apps with AI app builders like Rork and Replit shared lessons from taking those apps through Google Play review, including keeping testers opted in and engaged, aligning Data safety forms and privacy policies with actual model-provider network calls, and keeping API keys off the client bundle. The developer also built AppScore, an Android-only app that estimates Google Play and App Store approval odds, revenue ranges and rejection flags from a short idea description, and now runs a pre-build checklist covering policy risk, competition and differentiation.

I build small apps on my own, mostly with AI app builders like Rork and Replit. The code now shows up fast. The hard parts have moved to either end: picking the idea, and getting it through the store. Here's what I've learned taking apps through Google Play, and the habit I changed because of it. Testers have to stay opted in. If one drops off, you're under the bar. Recruit a few extra. Hitting the numbers isn't enough. Google looks at whether testers actually used the app, not just whether they opted in. If engagement is thin, you can be asked to run another 14 days. "Apply for production" asks how you recruited testers, how you collected feedback, and what you changed. Recruit people who will actually open the app, give them something specific to try, and keep notes as you go so you can answer honestly. Data safety and privacy have to match what the app really does AI apps send user text or photos to a model provider. Your Data safety form, your privacy policy, and your actual network calls need to tell the same story. I now write the privacy policy before I build, because it forces me to decide what data the idea really needs. Secrets don't belong in the app bundle With AI builders it's easy to end up with an API key in a public env variable that gets compiled into the app. Treat anything in the client as public, keep provider keys on a server, and scan your build for keys before you upload. A lot of review risk is decided before you write code Some ideas carry extra review work no matter how well they're built: apps that lean on user-generated content without a moderation plan, apps that copy a category leader too closely, or a subscription in a category full of free apps. Those are cheap to spot on day one and expensive to discover after you've built. The check I run now, before building For every idea, I write three sentences: what it does, who it's for, and how it makes money. Then I ask: Policy: Does it touch user content, health claims, kids, finance, impersonation, or faces? Each of those adds review work. Competition: Who are the top 3 to 5 apps in the category, and what do they charge? Difference: In one line, why would someone switch? I got tired of doing that by hand, so I built a small app for it, AppScore. You describe the idea and it gives you rough approval odds for Google Play and the App Store with the likely rejection flags, a ballpark revenue range, the main competitors, and what to change. It's an estimate, not a ruling from Google or Apple, but it gets me to "don't build this version" a lot faster. It's Android-only. Free with 3 idea checks a month, optional Pro subscription: https://play.google.com/store/apps/details?id=app.rork.app idea score potential https://play.google.com/store/apps/details?id=app.rork.app idea score potential Whether or not you use it, steal the checklist above. The cheapest rejection is the one you catch before you build. What's caught you out on Play review? I'm collecting real cases.