DEV Community: vmzavas

My Active Users Fell 82%. It Wasn't Churn, It Was a Bug

vmzavas — Sun, 11 Oct 2026 07:26:09 +0000

In June, PeerPlay's 30-day active users peaked at 709. By late August the number was 126, a drop of about 82%. I build and run PeerPlay on my own, so there was nobody else to look at that graph with me.

I did what most developers would do. I assumed people had tried the app, decided it wasn't for them, and left. I started writing a churn analysis. I was wrong, and the way I was wrong is worth sharing, because it applies to almost any small app.

The story I told myself
Churn is a comfortable explanation. It's normal, every app has it, and a test-swapping app has an obvious reason for it: developers join, get their testers, pass their 14 days and move on. The numbers fit that story well enough that I didn't question it.

So I was looking at the users. Who left, when, after doing what. That's a reasonable question, but it assumes the product is working the way you think it is.

What was actually happening
The real cause was a bug in the Discovery tab, the screen where developers find apps to test. It hid every app older than 14 days. That sounds harmless for a product built around 14-day rounds, except PeerPlay campaigns restart automatically. Apps that were still active, still looking for testers, simply disappeared from Discovery once they passed day 14.

So the people who opened PeerPlay found less and less to do, and the apps that needed testers got fewer of them. From the outside, that looks exactly like users losing interest.

The second bug that kept it quiet
A second bug at the same time made it worse. A developer's own My Apps list never showed that a campaign was paused. So nothing on screen hinted that anything was wrong, not for the testers browsing Discovery and not for the developers waiting for testers.

That's the part that stays with me. Two bugs, each small, and together they made a broken flow look like a calm, normal app with fewer users.

How I found it, and what changed
I didn't find it through monitoring or a bug report. I found it by accident while going through a Firebase analytics export, and I fixed it the same day.

After the fix, 30-day active users recovered to roughly 420 by late September. Not back to the June peak, but a long way from 126, and a clear sign that a lot of the drop had never been churn at all.

Why this is easy to miss when you build alone
When you're a solo developer, you're also the only person who uses the app with a full picture of how it's supposed to work. You know which apps should be in Discovery, so you rarely look at it the way a new user does. The empty space a user sees doesn't look empty to you.

There's also an emotional pull toward the churn story. A bug is your fault and has to be fixed today. Churn feels like the market's fault and can be analysed calmly. It's tempting to pick the explanation that asks less of you.

None of this needs a team to fix. It needs a habit: whenever a number moves sharply, assume the app first and the users second, and go and look.

What I'd check before calling it churn
First, look for anything time-based. Filters like "newer than X days", expiry dates and automatic restarts are where old assumptions hide. A rule that made sense when you wrote it can quietly break when another part of the app changes.

Second, check every state your app can be in and whether the user can see it. Paused, expired, waiting, hidden: if a state exists in your database but not on screen, nobody will ever report it, because nobody knows it's there.

Third, look at your raw data, not just the dashboard graph. An export lets you ask questions the dashboard wasn't built for, and that's where the answer was for me.

The same habit helps during a Google Play closed test. When testers seem to go quiet, check that the app is actually working for them before you decide they've lost interest. That's part of why PeerPlay checks that a tester really opened an app for a real session: it tells you whether people are using the app, or just have it installed.

12 Testers, 14 Days: 7 Myths That Cost Developers Time

vmzavas — Sat, 10 Oct 2026 10:22:40 +0000

Developers talk about the 12 testers for 14 days rule like it's a boss fight. Some of that is fair: finding a dozen people who'll keep an app installed for two weeks is genuinely hard when you're on your own.

But a lot of the time lost goes to things people believe about the rule that aren't true. Here are seven of them, roughly in the order they tend to bite.

Myth 1: Any 12 email addresses will do
Adding 12 addresses to an email list is step one, not the finish line. Each tester has to open the opt-in link, accept with that exact Google account, and install the app from the Play Store. People on the list who never opt in don't help you.

The classic version of this myth is a list full of friends' work emails, while their phones are signed in to personal Gmail accounts. Play Console sees a list of 12 and an opted-in count of 4.

Myth 2: The clock starts when you send the invites
The days that matter are days with enough opted-in testers. If you send invites on Monday and the twelfth person opts in on Thursday, Thursday is closer to your real day one. If someone opts out in week two and you fall under 12, you can lose progress.

That's why recruiting a few extra testers is cheap insurance. Fifteen people who stay beats twelve people you're nervously counting every morning.

Myths 3 and 4: Testers must review, and day 14 means you're live
Closed testers can send you private feedback through the Play Store, but they can't leave public ratings on your listing during a closed test. Nobody needs to write a review for the requirement, and asking for fake ones later is a policy problem of its own.

What actually helps is feedback you can act on: crashes, confusing screens, things people expected the app to do.

Nothing publishes automatically when the 14 days are up. You apply for production access in Play Console, answer questions about how the test went, and wait for Google's review. Only after that can you release to production.

Which leads to the next two myths.

Myths 5 and 6: It's just a box to tick, and you can't touch the app during it
The production application asks how you recruited testers, how they used the app, what feedback you got and what you changed. A test where nobody opened the app gives you nothing to write, and a vague application is a common reason for rejection.

So use the two weeks. Ship fixes to the closed track while the test runs; updating your test build is normal, and the application explicitly asks what you changed. Google's help pages don't describe a rule against updating mid-test, but check Play Console Help if you're unsure about your situation.

Myth 7: Passing the test is the hard part
When I wrote about PeerPlay on Indie Hackers, several readers pushed back on exactly this. Their point was that the harder wall comes after the 14 days: a brand-new app with zero ratings and almost no search visibility. One also pointed out that an organization account with a DUNS number skips the 12-tester rule altogether, which is worth knowing if you already run a registered business.

They were right. Treat the closed test as your first round of real users, not an obstacle course. The bugs you fix and the people you meet during it are what give a new listing a chance afterwards.

So what is actually hard?
Finding people who will keep an Android app installed and open it for two weeks. That's the real problem, and it's why I built PeerPlay after running into the requirement myself. Developers test each other's apps in tracked 14-day rounds, PeerPlay checks that a tester actually opened your app for a real session, and testers who go quiet are removed from the round so you can replace them before it costs you days.

Privacy Policy for a Small App: What Google Play Requires

vmzavas — Fri, 09 Oct 2026 09:18:11 +0000

A lot of solo developers find out about the privacy policy requirement at the worst moment: the app is built, the closed test is about to start, and Play Console shows a red mark next to App content. "My app doesn't collect anything" feels like a good reason to skip it. It usually isn't.

Here's what Google Play asks for, what a small app's policy actually needs to say, and the hosting mistakes that cause trouble in review. This isn't legal advice, and Google's policy pages change, so check the current Play Console Help article before you publish.

Does a small app really need one?
In practice, yes. Play Console asks for a privacy policy URL under App content for apps on Google Play, and you'll find it hard to get through review without one. Apps aimed at children and apps that handle personal or sensitive data have stricter rules on top.

Also, your app probably collects more than you think. If you use Firebase Analytics, Crashlytics, AdMob or almost any ad or analytics SDK, data such as device identifiers, crash logs and usage events leaves the phone. That counts, even if you never see it yourself. PeerPlay is a Flutter and Firebase app, and the analytics data Firebase collects was detailed enough that a Firebase analytics export is how I tracked down a real bug, which is a good reminder of how much these SDKs record.

What the policy should cover
Keep it short and specific to your app. A small app's policy can fit on one page if it answers these questions in plain language.

Who you are and how to contact you: your name or business name and an email address that works. What data the app collects, both what the user types in and what is collected automatically, including by third-party SDKs. Why you collect it, for example to run the app, fix crashes or show ads.

Who it's shared with: name the services involved, such as Firebase or your ad network, and link to their privacy policies. How long you keep data and how users can ask for it to be deleted. How you protect it, in general terms. And a date, so readers know which version they're looking at.

If your app truly collects nothing and uses no SDKs that do, say exactly that. A clear "this app does not collect or share personal data" is better than a generic template full of things you don't do.

Where to host it
The policy has to live at a public web address that anyone can open without signing in. Google's guidance says it should be an active, publicly accessible URL, not a PDF, and not something that can be edited by others. A page on your own website is the safest option. A free static page, such as GitHub Pages, works too.

Avoid links that change or break: a shared Google Doc can be edited and can lose its sharing settings, and a page on a free site builder can disappear when the trial ends. If the link goes dead after launch, your listing can get flagged later.

Put the same link in your store listing details and, for apps that handle personal data, inside the app as well, for example in a settings or about screen.

Make it match your Data safety form
Play Console also has a Data safety form where you declare what data your app collects and shares. Reviewers and users can compare the two, so they need to tell the same story. If the policy says you collect nothing but the Data safety form lists crash logs and device IDs, that mismatch is a reason for rejection.

The easiest way to get both right is to list your SDKs first. Most major SDK providers publish what their library collects for Data safety purposes. Use that list to fill in the form, then write the policy from the same list.

Before your closed test starts
Sort the privacy policy out before you invite testers, not after. App content items like this can hold up your release on the testing track too, and the 12 testers for 14 days that new personal accounts need are hard enough to organise without a paperwork delay in the middle.

Once the policy, Data safety form and store listing are done, you can focus on the testing itself. If you need real Android testers for that, PeerPlay lets developers test each other's apps in tracked 14-day rounds and checks that testers actually open your app, not just install it.

Can Testers Use an Emulator for Closed Testing?

vmzavas — Thu, 08 Oct 2026 08:54:06 +0000

Sooner or later every developer stuck at 9 or 10 testers has the same idea. Android Studio can run as many virtual phones as your laptop can handle, and each one can sign in to a Google account. Why not fill the last few slots that way?

It's a fair question, and the honest answer has two parts: what the emulator can technically do, and what it does to your chances when you apply for production.

What an emulator can actually do
Android Studio's emulator comes with different system images. The ones marked Google Play include the Play Store, so you can sign in with a Google account, open the opt-in link, accept the invitation and install the closed test build just like on a phone.

Images without Google Play, such as the plain Google APIs or AOSP ones, can't do that. You can sideload an APK onto them for your own debugging, but that install doesn't go through Play and has nothing to do with your closed test.

So a tester who has no Android phone but uses Android Studio on a computer can, in principle, take part. That's the narrow case where an emulator is a reasonable answer.

Keep in mind what the emulator can't show you. It runs on your computer's processor and memory, so performance, battery use, camera behaviour and some sensors look different from a real phone. Bugs that only appear on a specific manufacturer's Android version won't show up either.

Why it's a risky way to reach 12
The rule for new personal developer accounts asks for at least 12 testers opted in to a closed test for 14 days in a row. The point behind it is that real people use your app before the public does. Google doesn't publish how it checks testers, so I can't tell you exactly what it sees about emulator installs, and I wouldn't bet a developer account on it seeing nothing.

The bigger problem is what you'd be doing. One person running several emulators with several Google accounts isn't testing with real users; it's manufacturing them. Google Play's policies are strict about fake engagement and about the accounts behind it, and the downside of getting that wrong is much worse than two more weeks of recruiting.

Even if nothing is flagged, you still have to apply for production. Play Console asks how you recruited testers, how they used the app and what you changed based on their feedback. Emulators don't give feedback, so you end up with weaker answers at exactly the moment they matter.

Where emulators do help
Emulators are great for your own testing. Run the release build on a few screen sizes and Android versions before you share the opt-in link, check that sign-up works, and make sure the app doesn't crash on a small, low-memory device profile. The fewer crashes your real testers hit on day one, the more of them stay for 14 days.

Play Console's pre-launch report is also worth a look. When you upload a build, Google can run it automatically on a set of test devices and report crashes and accessibility issues. It doesn't count toward your testers, but it's free feedback you didn't have to recruit for.

If a real tester only has a computer
Sometimes a genuine tester, often another developer, wants to help but uses an iPhone day to day. If they already run Android Studio, an emulator with Google Play is a reasonable way for them to take part. Ask them to sign in with the same Google account they gave you for the email list or Google Group, then opt in and install from the Play Store inside the emulator.

Be realistic about it, though. An emulator only runs while their computer is on and Android Studio is open, so they're much less likely to open your app regularly over 14 days than someone with it on their phone. Treat these testers as extras, not as part of your core 12.

If you rely on a few of them, check in during the test. A short message around day 5 and day 10 asking whether they've opened the app recently is enough to catch anyone who has drifted away.

Getting real testers instead
If you're short by a few people, ask your existing testers to bring one Android-using friend each, post in developer communities that do testing swaps, and recruit more than 12 so a dropout doesn't reset your progress.

I built PeerPlay after running into the 12-tester requirement with my own Android app. Developers test each other's apps in tracked 14-day rounds, and PeerPlay checks that a tester actually opened your app for a real session rather than just installing it. Testers who go quiet are removed from the round, so you see a drop early and can replace them with someone real.

Do iPhone Users Count as Google Play Testers?

vmzavas — Wed, 07 Oct 2026 07:08:29 +0000

Half your friends probably have iPhones. When you need 12 testers for a Google Play closed test, it's tempting to count them anyway: they have Google accounts, they're happy to help, and the opt-in link opens fine in Safari.

The short answer is that they can join, but they can't test. That gap matters more than it looks.

This guide explains what an iPhone user can do with your closed test invite, why counting them is risky, and where to find testers whose phones can actually run your app.

What an iPhone user can and can't do
The opt-in page for a closed test is a normal web page. Anyone on your email list or in your Google Group can open it on any device, sign in with their Google account and accept the invitation. That part works on an iPhone.

What they can't do is install the app. Your test build is an Android App Bundle delivered through the Google Play Store, and there's no Play Store on iOS. The tester can see the Play listing on the web, but the install button only works for an Android device signed in to the same Google account.

There's also no workaround on the iPhone itself. Android apps don't run on iOS, and sideloading an APK isn't possible there either. If someone tells you they installed your test build on an iPhone, they most likely installed something else, or they're looking at the store page in a browser.

Do they count toward the 12?
Google describes the requirement for new personal developer accounts as at least 12 testers opted in to a closed test for 14 consecutive days. Google doesn't publish exactly how it checks each tester, so I can't promise how an opted-in tester who never installed is treated.

What I can say is that counting them is a bad bet. When you apply for production, Play Console asks about your closed test: how you recruited testers, what they did, what feedback you got and what you changed. A test where several people never opened the app gives you weak answers there, and a production rejection costs you more time than finding a few Android users would have.

There's also a practical problem during the test itself. You can't tell from the outside whether an opted-in tester is using the app, so a few iPhone users can make your list look healthy while the real number of people opening the app is much lower. If one of your Android testers drops out on day 9, you find out late that you never had a real margin.

Ways an iPhone user can still help
Check whether they have any Android device lying around. An old Android phone or an Android tablet with the Play Store works fine, as long as it's signed in with the same Google account they opted in with. Many Chromebooks also run Android apps from the Play Store, though how well your app behaves there depends on the app.

If they don't, ask them to help in other ways: review your store listing and screenshots, or pass the opt-in link to someone they know with an Android phone. That's worth more than an opt-in that never turns into an install.

Check who can actually test before you start
Before you send the opt-in link to anyone, ask one simple question: which phone do you use every day? It takes ten seconds and saves you from planning around testers who can't install anything.

Then ask each Android tester which Google account their Play Store uses. People often have two or three Google accounts, and the one they give you for the email list isn't always the one on their phone. A mismatch looks exactly like the iPhone problem: the tester is on your list, but the Play Store says the app isn't available.

Once the test is running, ask testers to tell you when they've installed and opened the app, and look at your own analytics or crash reporting for new sessions. That's a better signal than the opted-in number alone.

Find testers who are actually on Android
The developers most likely to have Android phones are other Android developers, and they're also the ones who need testers themselves. That's the idea behind a swap: you test their app, they test yours.

I built PeerPlay after running into the 12-tester requirement with my own Android app. Developers test each other's apps in tracked 14-day rounds, and PeerPlay checks that a tester actually opened your app for a real session, not just installed it. Testers who go quiet are removed from the round, so you can replace them before your count drops.

Unity Game on Google Play: Passing Closed Testing

vmzavas — Tue, 06 Oct 2026 13:46:15 +0000

Games have one advantage in closed testing that utility apps don't: people actually want to open them. The catch is everything before that. A Unity project that runs fine in the editor can still be rejected at upload, crash on a cheap phone, or show live ads to your own testers.

This guide covers the Unity build settings first, then how to get a game through the 12 testers and 14 days that new personal accounts need.

Set up the Android build in Unity
Open Build Settings (called Build Profiles in Unity 6), select Android and switch the platform. Then go to Player Settings and set the Package Name. It becomes your app's ID on Google Play and can't be changed after the first upload, so pick it carefully.

Under Other Settings, set the Scripting Backend to IL2CPP and tick ARM64 under Target Architectures. Google Play requires 64-bit support, and a Mono build only produces 32-bit ARM code, which is a common reason for an upload being rejected.

Set the Target API Level to the highest one your Unity version offers, or check what Google Play currently requires. Play raises the minimum target API level every year, and older Unity versions may need an updated Android SDK to reach it.

Build a signed App Bundle
Google Play wants an Android App Bundle (.aab) for new apps. In Build Settings, tick Build App Bundle (Google Play) before you build, otherwise you'll get an APK.

In Player Settings, under Publishing Settings, create a new keystore with the Keystore Manager and use it for the release build. Don't upload a build signed with the debug key. Keep the keystore file and its passwords somewhere safe, because every future update has to be signed with the same upload key. With Play App Signing, Google holds the final signing key, which makes a lost upload key recoverable.

Bump the Bundle Version Code in Player Settings for every new upload. Play Console rejects a bundle whose version code it has already seen, and you'll probably upload several builds during the test.

Game-specific things to check before testers arrive
If your game shows ads, switch to test ads for the closed test. Ad networks treat clicks from people close to the developer as invalid traffic, and your testers are exactly that group. AdMob, for example, provides test ad units for this.

Large games can hit the size limit for the base download. Unity supports Play Asset Delivery for moving big asset packs out of the base module; check the current limits in Play Console Help before you assume you're under them.

Test on at least one older or low-memory phone yourself. Shader compile stutters, texture memory crashes and missing permissions show up there first, and a crash on day one is the fastest way to lose a tester.

Running the 14-day closed test
Upload the .aab to a closed testing track, add testers through an email list or a Google Group, and share the opt-in link. If your personal developer account is new, you need 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 check Play Console Help for your own account.

Recruit a few more than 12, because the days only count while you have enough opted-in testers. Give players something concrete to do, like reaching level 3 or trying the shop, rather than asking them to just play.

If you don't have 12 people, PeerPlay is built for this. Developers test each other's apps in tracked 14-day rounds, PeerPlay checks that a tester opened your game for a real session rather than just installing it, and testers who go quiet are removed from the round.

Turn the test into your production application
When you apply for production, Play Console asks how you tested, what feedback you got and what you changed. For a game that's easy to answer well: crashes on specific devices, levels that were too hard, controls that confused people. Write those down during the test, ship fixes as new builds, and you'll have real answers instead of a vague paragraph.

First Paid Closed Test: How Nada Got Production Access

vmzavas — Tue, 06 Oct 2026 09:04:43 +0000

On October 6, 2026 an email arrived in a developer's Play Console inbox: "Congratulations! Your app has been granted Google Play production access." The app was Nada, and it was the first app that went through a paid campaign on PeerPlay.

This is the full case study, with the numbers taken straight from the campaign report. I'm writing it down because one real paid campaign taught me more about closed testing than a long list of free ones, and because the same lessons apply to anyone who is about to start their own 14 days.

What Nada Is and What the Developer Bought
Nada is a women's health app built around cycle and period tracking. It has logs with notes, schedules and reminders, and a step where the user takes a photo with the camera. The developer already had the app on PeerPlay's free reciprocal tier with a few testers on it.

They upgraded to Starter Pro, which costs $24.99 one-time and gives 15 verified testers with no reciprocal testing needed. The testers on that plan were approved by hand and test on physical devices. The upgrade kept the testers the developer already had, so nobody had to opt in twice.

What I Had to Fix Before Taking the Money
Having a paying customer made me read my own campaign code with different eyes, and it was not ready. A paid campaign had no fixed end date. Every tester ran their own 14-day round, and a restart button could have paid every tester for another round the customer never bought. The end-of-round tester bonus could also be collected by someone who skipped most of the days.

While Nada's campaign was running I rebuilt that part. A paid campaign now has one calendar for everyone, the bonus needs at least 12 qualified days out of 14, and the server pays it instead of the phone. Your first customer is the most honest code review you will get.

The 14 Days in Numbers
The campaign ran from September 16 to October 6, 2026. In total 18 testers joined, 11 of them completed the full 14 days and 3 quit along the way. The daily log has 217 tester-days, and every one of them qualified.

Day one was slow, with only 7 testers active. From the second day the count stayed between 12 and 15 every day, and it never dropped below 12 between September 17 and October 1. The devices covered Android 9 through Android 17 on Samsung, Xiaomi, OPPO, Google Pixel, Nothing, HONOR, Motorola and Infinix phones.

Most daily sessions in the log are under a minute and still count as qualified. What carried the test was not long sessions, it was the same people opening the app every single day.

What the Testers Actually Found
I expected testers to be a number Google wants to see. They turned out to be QA. The report lists 14 feedback items, and the developer marked 8 of them as solved during the test.

Some of the bugs: turning off a schedule with its switch did nothing, and deleting a schedule did not update the screen until you left and came back. Cycle tracking stopped somewhere around the 19th cycle. A new period entry did not properly close the previous one. The quotation marks in log notes were reversed, and the privacy statement had extra spaces in a sentence. One tester reported that the app did not launch on their phone.

There were feature ideas too: a dark mode for use at night, the front camera (or a switch between cameras) for the photo step so people can see the preview, and health tips during periods. None of this would have shown up on the developer's own phone.

Five Lessons for Your Own Closed Test
Plan for a slow first day. Only 7 testers were active on day one, so count your 14 days from when you really have 12 people, not from when you sent the invites.

Get more testers than the minimum. 3 of 18 testers quit, and the extra slots are what kept the daily count at 12 or more. With exactly 12 people, one dropout means trouble.

Daily presence beats session length. Short daily sessions qualified; skipped days are what hurt.

Treat testers as QA, not a headcount. Read every piece of feedback and reply. The version of Nada that went to production was better than the one that started the test.

Keep the test running until Google answers. Google doesn't publish exactly what it checks during the production review, so leaving the closed test alone until the approval email arrives is the safe choice.

Google Groups vs Email Lists for Closed Testing Testers

vmzavas — Mon, 05 Oct 2026 06:41:13 +0000

Play Console asks a small question when you set up a closed test that turns out to matter for the next two weeks: who is allowed in, and how do you tell Google about them? You can paste addresses into an email list, or point the track at a Google Group.

Both work. Both can get you to 12 opted-in testers. The difference is how much typing you do, how fast new testers can join, and how much control you keep when someone needs to be removed.

How email lists work
On your closed testing track, open the Testers tab and create an email list. You give it a name and add addresses, either one by one or by uploading a CSV file. Every address needs to be the Google account the tester uses for the Play Store, usually a Gmail address.

The list lives inside Play Console, so you are the only person who decides who's on it. If a tester sends you the wrong address, or uses a different account on their phone than the one they gave you, the opt-in page won't let them in until you fix the list.

Lists can be reused across tracks and apps in the same developer account, which is handy if you test more than one app with the same group of people.

How Google Groups work
With a Google Group, you create the group in Google Groups first and then enter the group's email address on the track instead of individual testers. Anyone who is a member of that group can opt in.

The big advantage is that testers can join on their own. If you set the group so anyone can join, you share two links: the group link and the opt-in link. You don't have to collect addresses in a chat or a spreadsheet and copy them into Play Console, which removes the most common typo problem.

Two settings are worth checking before you share it. Set who can see the member list to owners or managers only, so testers can't see each other's email addresses. And decide whether people can join directly or have to ask, depending on how open you want the test to be.

Which one fits your test
Use an email list when you know every tester personally and the group is small: a few friends, colleagues, or developers you swapped testing with one by one. You have the addresses anyway, and you get exact control.

Use a Google Group when you're recruiting more widely, posting the test in a community, or expect people to come and go. Letting testers join themselves saves you hours of copying addresses, and it scales if you decide to recruit 20 people to keep 12 active.

You can also attach both to the same track. Some developers keep a core email list of people they trust and a Google Group for everyone else.

Mistakes that cost testers with either method
Being on the list or in the group is not the same as being opted in. The tester still has to open the opt-in link while signed in with that same Google account, accept the invite, and install the app from the Play Store. Check the opted-in count in Play Console, not the size of your list.

Account mismatches cause most of the confusion. A tester joins the group with a work account but their phone uses a personal one, and the Play Store says the app isn't available. Ask testers which account their phone's Play Store uses before they join anything.

Removing someone also works differently. With a list you edit it in Play Console; with a group you remove them from the group. I'm not certain how quickly Play reflects a group change in every case, so don't make last-minute membership edits right before you apply for production.

Keeping the count steady for 14 days
Neither method keeps testers active. That part is people, not settings. Recruit a few more than 12, remind people mid-way through, and watch the opted-in count every few days so a drop doesn't surprise you.

I built PeerPlay after hitting this wall with my own app. Developers test each other's apps in tracked 14-day rounds, PeerPlay checks that a tester really opened the app for a real session, and testers who go quiet get removed from a round, so you find out about a drop while there's still time to replace someone.

Vibe-Coded App to Google Play: Getting Through Testing

vmzavas — Sun, 04 Oct 2026 07:52:40 +0000

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.

DUNS Number for Google Play: What It Is and How to Get One

vmzavas — Sat, 03 Oct 2026 05:50:08 +0000

Here's the tradeoff in one line: a DUNS number costs you paperwork and waiting time up front, and in return an organization account skips the 12 testers for 14 days that personal accounts have to get through. Whether that's a good deal depends on one question. Do you already have a registered business?

If you do, getting a DUNS number is mostly a form and some patience. If you don't, you'd be setting up a company just to avoid a two-week test, and that's rarely worth it for one app.

What a DUNS number actually is
DUNS stands for Data Universal Numbering System. It's a nine-digit number that Dun & Bradstreet assigns to a business so it can be identified in their database. It isn't a tax number and it isn't a business license. It's closer to a public ID card for a company, used by governments, large suppliers and platforms like Google and Apple to check that a business is real.

Google Play uses it during developer account verification. When you create an account as an organization, Google asks for your DUNS number and checks your organization's name and address against what Dun & Bradstreet has on file.

Why it matters for closed testing
The 12-tester requirement applies to personal developer accounts created on or after November 13, 2023. Organization accounts are currently exempt. That's the whole reason this topic keeps coming up.

When I wrote about PeerPlay on Indie Hackers, one of the most useful replies pointed out exactly this: an organization account with a DUNS number skips the 12-tester rule altogether. It's true, and for some developers it's the better route. It's just not free of friction, and Google's rules for both account types can change, so check Play Console Help before you commit.

Who can get one
You need a legal business entity. Depending on your country that might be a limited company, an LLC, or in many places a registered sole trader. What you can't do is register a hobby project with no legal form behind it.

Before you request anything, search for your company first. Dun & Bradstreet may already have created a record for your business from public registers, in which case you only need to look up the existing number and make sure the details are current.

How to request it
Dun & Bradstreet offers a free DUNS request. Google Play's own help pages link to the lookup and request flow, and that's the safest place to start, because it routes you to the right form for your country instead of a paid service with a similar name.

Fill in the legal name exactly as it appears in your business registration, plus the registered address, phone number and a contact person. Small differences cause problems later. If D&B has "Example Apps d.o.o." and you type "Example Apps" in Play Console, verification can stall.

Then wait. The free route can take weeks; Dun & Bradstreet's own guidance has mentioned up to 30 business days, and in some countries it's faster. They also sell expedited options. I'd only pay for those if a launch date truly depends on it, since closed testing on a personal account takes about two weeks anyway.

After you have the number
Use it when creating the organization developer account, or when your existing organization account asks you to verify. Google may ask for additional documents, and it also verifies a contact email and phone number. Keep the business details identical everywhere: D&B, Play Console and your public developer profile.

One practical note: an organization account shows your organization's details to users on Google Play. If your business is registered at your home address, think about whether you're comfortable with that before you go down this path.

So which route should you take?
If you already run a registered business, get the DUNS number and open an organization account. You'll skip the tester requirement and look more established on the store.

If you're a solo developer with one app and no company, I'd stay with a personal account and run the closed test. Two weeks of testing with real people is less work than forming a company, and you'll come out of it with actual feedback. That's the situation PeerPlay was built for: developers swap testing in tracked 14-day rounds, so you're not stuck trying to find 12 people on your own.

Can You Remove Testers Once the 14 Days Are Up?

vmzavas — Fri, 02 Oct 2026 17:16:15 +0000

Removing testers is easy. Doing it at the wrong moment is the mistake. Once your 14 consecutive days pass and the Apply for Production button becomes available, it is tempting to clear out email lists or delete your Google Group right away. You can remove testers after closed testing on Google Play, but I'd wait until Google has approved your production application.

I built PeerPlay after running into the 12-tester requirement myself with my own Android app and not being able to find 12 real testers, so I understand the urge to wrap things up. It makes sense if you borrowed email addresses from friends or used an exchange service. But Google doesn't publish exactly what it checks during the production review, and that uncertainty is the reason to leave the track alone until the review is done.

When You Can Safely Remove Closed Testers
The cautious answer is: after your application for production access has been reviewed and approved. Passing day 14 only satisfies the timer in Play Console. It lets you submit the production access questionnaire, and that application is then reviewed, partly based on how your closed test went.

I can't tell you for certain whether Google looks at your current tester list while an application is pending. What I can say is that an empty track or a deleted Google Group gains you nothing during that window, and a rejection would cost you far more time than a few extra days of patience. So wait until the app is approved and live in production before removing opt-ins or closing testing lists.

What Happens If You Delete Your Testing List Too Early
Removing email addresses or deleting the Google Group revokes access to the test for those accounts, and your opted-in count drops with it. During the 14 days that matters directly, because the requirement is 12 testers opted in continuously. After day 14, nobody outside Google knows exactly how a falling count is weighed during review, which is why I treat the review period as part of the test.

My advice is to leave the Google Group running until the production application status changes to approved. Once approved, losing closed testers will not affect your published production version. However, keeping those early users attached to your track is helpful if you ever need to test an update before releasing it to everyone.

How to Remove Testers From Google Play Console
When you are ready to remove testers after production approval, the process depends on whether you managed access through email lists or a Google Group. If you added individual email addresses directly into a custom email list in Play Console, navigate to Testing, select Closed testing, click the Testers tab, and edit or delete the list.

If you used a Google Group, removing members from the group automatically revokes their access to the closed testing build. You can remove individual members inside Google Groups settings or delete the entire group. Alternatively, you can simply uncheck the Google Group inside the Play Console closed testing track settings and save changes.

Keep in mind that revoking tester access does not uninstall the app from their physical devices. It simply prevents them from downloading future closed testing updates and disables their ability to leave private tester feedback on your Play Store listing.

Managing Testers for Future App Updates
Even after reaching production, closed testing tracks remain useful for staging major updates. Rather than removing every tester, consider keeping a core group of engaged users who actively opened your app. PeerPlay helps developers find testers in tracked 14-day rounds by checking that a tester actually opened the app for a real minimum session, which is useful when you need genuine feedback on new features.

If you choose to clear your list completely, you can always create a new closed testing track or an open testing track later. Open testing does not require email lists or 14-day streak rules, making it easier to gather public feedback once your developer account has passed its initial production access hurdle.

Handling Tester Opt-Outs After Day 14
Sometimes testers will remove themselves from your Google Group or opt out of your testing track once the 14 days finish. If you recruited testers through online groups or reciprocal swaps, some participants naturally leave as soon as their commitment ends.

To protect yourself, keep a buffer of 15 to 20 testers throughout the 14 days and until production approval comes through. Then, even if three or four people leave the moment the counter hits 14, you stay above 12 while the application is being reviewed.

Publish a Flutter App on Google Play: The Testing Step

vmzavas — Fri, 02 Oct 2026 06:00:55 +0000

Here's the path from your next click to a Flutter build sitting on a closed testing track. First you sign the app, then you build an app bundle, then you upload it to a closed track in Play Console and invite testers. Production comes after the 14 days, not before.

PeerPlay itself is a Flutter and Firebase app, so this is the route I know best. Most of it is standard Android publishing. A few steps are specific to Flutter, and those are the ones that trip people up.

Fix the package name before anything else
A new Flutter project starts with an application ID like com.example.your_app. Play Console won't accept a package name that starts with com.example, and once you upload a build with a given package name, that name belongs to the app for good. You can't rename it later.

Change the applicationId in your android/app build file to something you own, such as com.yourname.appname, before the first upload. If you also changed the namespace or the Kotlin package folder, run the app once on a device to make sure nothing broke.

Sign the release build
Debug builds are signed with a debug key that Play Console rejects. You need an upload key. Create one with the keytool command that ships with the JDK, keep the .jks file somewhere outside the project, and back it up. Losing it is fixable through Play Console support, but it's a hassle you don't want.

The Flutter docs show the usual setup: a key.properties file with the store path and passwords, and a signingConfigs block in the android/app build file that reads it for the release build type. Keep key.properties out of git. On new apps Google manages the real app signing key through Play App Signing, so the key on your machine is only used to prove the uploads come from you.

Build the app bundle and set the version
Google Play wants an Android App Bundle, not an APK. Run flutter build appbundle and the output lands in build/app/outputs/bundle/release as app-release.aab.

Look at the version line in pubspec.yaml, something like 1.0.0+1. The part before the plus is the version name users see. The number after it becomes the version code, and Play Console rejects any upload whose version code it has already seen. Bump that number every time, even for a tiny fix during the test. It's the most common reason a second upload fails.

Before you upload, run the release build on a real phone with flutter run --release. Release builds strip debug tooling and can behave differently, especially around code shrinking and plugins that need extra rules.

Getting the build onto a closed track
In Play Console, open Testing, then Closed testing, and create a release on the track. Upload app-release.aab, add release notes and save. Then fill in whatever the dashboard still flags as missing: store listing, content rating, data safety, target audience and the app access details if your app has a login. Google reviews the first release, so incomplete forms just delay you.

On the Testers tab, attach an email list or Google Group and copy the opt-in link. Testers have to open that link and accept the invite with the same Google account they use in the Play Store. Adding them to a list alone doesn't count them.

If you want a sanity check first, the internal testing track is useful for making sure the bundle installs and starts properly on a few of your own devices. It doesn't count toward the closed testing requirement, so don't wait on it long.

Flutter details that matter during the 14 days
You can ship updates while the test is running. Upload a new bundle with a higher build number to the same closed track and testers get it as a normal update. That doesn't remove anyone from the test.

If you use Firebase, add the SHA-1 and SHA-256 fingerprints of the Play App Signing key from Play Console to your Firebase project, not only your local debug and upload keys. Google sign-in that works on your machine and fails for every tester is very often this.

And make sure testers actually open the app. A tester who installs and never launches it tells you nothing, and the production application asks what you learned from the test. That's the gap PeerPlay was built around: testers are swapped between developers and tracked for real sessions over the 14 days, not just installs.