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.
Top comments (0)