Listing Moneyflow on the Google Play Store

Behind the scenes · September 2026

Moneyflow started as a browser game. Getting the same game onto Google Play took considerably longer than building the Android build itself. Here is the honest version of what that process looks like, in the order we hit each step - so that if you are shipping your own game, you know what is waiting for you.

Get Moneyflow on Google Play

1. Wrapping the web game as a real Android app

Moneyflow is a React app, so we used Capacitor to package it as a native Android project rather than rewriting the game. The application ID is com.playmoneyflow.app - and it is worth knowing that this string is permanent. Once a package name is published to Play, it can never be reused or renamed, so it is one of the few decisions in the whole pipeline you genuinely cannot undo.

Play requires an Android App Bundle (.aab), not an APK, and it must be signed. We let Google manage the app signing key and kept the upload key in a place we will still be able to find in three years. Losing the upload key is recoverable; losing control of the listing is not.

2. Closed testing: the part nobody warns you about

For new personal developer accounts, Google requires a period of closed testing with real testers before you are even allowed to apply for production access. That means recruiting testers, having them opt in through a link, and keeping them genuinely enrolled for the full window - not just clicking a button once.

What we would do differently: start closed testing on day one, with a rough build.

The clock only runs while testers are opted in. If you wait until the game is polished, you have added weeks to your launch date for no reason. Ship an ugly build to the testing track early and polish while the timer runs.

3. The Data safety form

This is a declaration, and Google cross-checks it against what your app actually does. Every SDK you bundle counts as your behaviour, not theirs. For Moneyflow we had to account for:

The rule we followed: if a field is ambiguous, describe the behaviour honestly and in the broader category. An over-declaration costs you nothing. An under-declaration is a policy violation that can take the listing down after it is already live, which is a far worse day.

4. Content rating and the "is this gambling?" question

Moneyflow is a board game about money. It has dice, assets, and a stock market. That combination reliably triggers questions in the content rating questionnaire, so it is worth being precise about the distinction:

It is a simulation of financial decisions, in the same way a flight simulator is not a flight. Answering the questionnaire literally and consistently is what matters - the rating is generated from your answers, and a mismatch between your answers and your actual gameplay is grounds for removal.

5. In-app purchases

Play requires every product to be created and activated in the Play Console before your app can see it, and products only resolve for a build that has already been uploaded to a testing track with the billing permission. This catches almost everyone: your paywall comes back empty, the code looks perfect, and the actual problem is that the store has nothing to hand you.

We ended up with dozens of products across tiers, which is too many to click through a web form reliably. We wrote scripts to create and audit them instead, and used RevenueCat as the layer between the app and the store so that the same entitlement logic works on both Android and iOS. Testing purchases requires license tester accounts configured in the Play Console - real charges never happen, but the full purchase flow does.

6. Account deletion is mandatory

If your app lets a user create an account, Google requires a way to delete that account - both inside the app and through a publicly reachable web URL, so that someone who has already uninstalled can still get their data removed.

We nearly submitted without this. Moneyflow now has account deletion in the in-app menu and a public page at playmoneyflow.com/delete-account. If you support sign-in at all, build this before you submit rather than after a rejection.

7. The store listing itself

The listing is a marketing asset, not paperwork, and it is where most of the eventual install decisions get made. What Play asks for:

Screenshots do the heavy lifting. For a board game, showing the actual board in the first two frames beats any amount of description copy - people decide from the images before they scroll.

8. Review, and what actually goes wrong

Review times vary from a couple of days to well over a week, and a first submission from a new account tends to sit at the slow end of that range. In our experience the rejections that happen are almost never about the code. They are about the metadata around it: a Data safety answer that does not match the app's behaviour, a missing privacy policy URL, a screenshot that shows something the build no longer does, or a permission declared in the manifest with no visible feature behind it.

What we would tell ourselves at the start

  1. Create the Play Console account and start closed testing immediately. The waiting period is the critical path, and it is the one thing you cannot compress later.
  2. Write the privacy policy, terms, and account deletion page before writing the store listing. They are prerequisites, not paperwork you tidy up at the end.
  3. Script anything you would otherwise click more than ten times. In-app purchase products especially.
  4. Answer every questionnaire literally. The forms are compared against your actual app, so the honest answer is also the fast one.
  5. Budget for the boring half. Roughly speaking, building the Android build was the smaller job; store compliance was the larger one.

Play it now

Moneyflow is free on Android, and free to play in any browser at playmoneyflow.com - no install, no account required to start. Pick a character with real income, expenses, and debt, then build enough passive income to escape the 9-to-5.

Get it on Google Play