Getting an app to run with Cursor, Claude, Lovable or Bolt is the fast part now. The slow part starts when you open Play Console and it asks for things the AI never mentioned: a signed bundle, a privacy policy, a Data safety form, and on a new personal account, 12 testers who keep the app installed for 14 days.
None of that is harder for a vibe-coded app than for a hand-written one. It just tends to arrive as a surprise. Here's the order I'd do it in.
First, know what kind of app you actually have
Ask your tool, or read the project files, and find out which of these it is. A Flutter project has a pubspec.yaml file. A React Native or Expo project has a package.json with react-native or expo in it. A web app from Lovable, Bolt or a similar builder is usually React running in the browser, and it isn't an Android app yet.
This matters because the build step is different for each. Flutter builds an upload file with flutter build appbundle. Expo projects are usually built with EAS Build (eas build --platform android), which produces an .aab by default. A web app needs a wrapper first, such as Capacitor (npx cap add android, then open the project in Android Studio) or a Trusted Web Activity if it's a PWA.
Whatever the route, Google Play wants an Android App Bundle (.aab) for new apps, not an APK, and it has to be a signed release build, not the debug build you ran on your phone.
Fix the things AI tools usually skip
Before anyone else installs the app, go through it with a few questions the generator didn't ask itself. Are API keys for paid services sitting inside the app where anyone can pull them out? Does the backend trust whatever the device sends? Are there placeholder screens, lorem ipsum, or buttons that do nothing?
The backend one is the one I'd check hardest. PeerPlay is a Flutter and Firebase app I build on my own, and I once found that a developer's wallet balance was writable straight from their own device with no server-side check. Nothing looked wrong in the app. It only showed up when I read the rules. If your AI tool set up Firebase, Supabase or a similar service for you, open the security rules and read them line by line.
Also check the app ID (applicationId in the Android build file). You can't change it after the first upload, and generated projects often ship with something like com.example.app.
Wrapped web apps need to do more than show a website
Google Play has policies against apps that offer very little functionality, and a thin wrapper around a website can run into them. I can't tell you exactly where Google draws that line, and it's worth reading the current policy page yourself.
In practice, an app that works offline in some way, uses device features like notifications or the camera, and doesn't look like a browser tab has a much easier time in review. It also gives your testers something real to use during the closed test.
Getting through the 14-day closed test
If your personal developer account is new, you'll need a closed test with at least 12 testers who stay opted in for 14 days in a row before you can apply for production. Organization accounts currently aren't subject to this, but Google's rules change, so confirm it in Play Console Help for your own account.
Upload your .aab to a closed testing track, add testers through an email list or a Google Group, and share the opt-in link. The 14 days only count while you have enough opted-in testers, so recruit a few more than 12 in case someone drops out.
This is where most vibe-coded projects stall, because the builder has no audience yet. I ran into the same wall with my own app, which is why I built PeerPlay. Developers test each other's apps in tracked 14-day rounds, and the app checks that a tester really opened your app for a real session, not just installed it.
Use the testing time to actually test
Twelve people on different phones will find crashes you never saw on your own device, especially in AI-written code that was only ever run on one emulator. Ask them to try sign-up, the main feature and anything involving payments or permissions.
Keep a short list of what they report and what you fixed. When you apply for production, Play Console asks how you tested and what you changed, and a vague answer is a common reason for a rejection. Real fixes from real testers are the easiest thing to write about.
Top comments (0)