Blog

A Solo Developer's Timeline From First Build to Production on Google Play

A Solo Developer's Timeline From First Build to Production on Google Play

If you are a solo developer with a new personal Google Play account, the path to production takes roughly four to five weeks of calendar time. That is a planning estimate, not a guarantee. The closed test alone takes at least 14 days, and Google's review time is outside your control.

Below is a phased timeline you can adapt. The phases are firm. The durations are flexible and depend on your app and how fast you can fix things.

The rule that shapes the timeline

Since November 13, 2023, new personal developer accounts must run a closed test before applying for production access. The requirement started at 20 testers and is now 12 testers opted in for 14 days in a row. Everything else in your schedule works around that 14-day block.

Google Play rules change, and details can differ by account type and date. Check Play Console Help for the current wording before you plan around any number in this post.

Phase 1: Build and prepare (about 1 to 2 weeks)

This is the work you control completely, so do it before the clock starts. Once the 14 days begin, a broken build costs you time you can't get back.

What to finish first

  • A stable build. It should install, launch and complete its main flow without crashing. It doesn't need to be perfect, but testers should be able to use it.
  • A signed Android App Bundle (AAB). Set up app signing early so you aren't solving key problems on upload day.
  • A first draft of your store listing. Name, short description, full description, icon and a few screenshots. You can polish later.
  • Policy forms. Start on the content rating, target audience and Data Safety form. They are easy to underestimate and tedious to rush.
  • Test access. If your app needs a login, prepare a test account or a way for testers to sign up.

You don't need to be feature-complete. You need a build you can describe honestly and testers can use for 14 days.

Phase 2: Create the closed track and upload (1 day)

In Play Console, create the app, open the closed testing section, create a track and upload your AAB. Add your testers by email list or Google Group, and copy the opt-in link.

Two things trip people up here:

  1. Testers must accept the invitation through the opt-in link. Being on the list isn't enough.
  2. After a first upload, the app can take a while to become visible to testers. Don't assume it's broken in the first hour.

Phase 3: Recruit and confirm testers (days 1 to 3)

This is where solo developers most often lose time. Friends and family say yes and then forget, or can't install the app because of their device or region. The 14-day counter needs 12 people staying opted in, so a few dropouts can be a problem.

A practical approach:

  • Recruit more than 12 people, so one or two dropouts don't stop you.
  • Send clear instructions: the opt-in link, the Google account to use, and what to do after installing.
  • Check the tester count in Play Console after a day or two, rather than trusting that everyone joined.

If you don't have enough people you trust to stay engaged, a testing service is one option. TesterMob provides real testers on their own Android phones who use your app about 20 minutes a day and leave written feedback. It costs $9.99 per app, once, paid in USDT, with no subscription. It is a convenience, not a shortcut around the rules, and it can't guarantee that Google approves you. The FAQ covers how it works in more detail.

Phase 4: Run the 14 days (days 1 to 14)

Once 12 testers are opted in, the clock runs. Your job is not to sit and wait.

A rough rhythm for the two weeks

  • Days 1 to 3: Watch for install problems and crash reports. Fix anything that blocks basic use.
  • Days 4 to 10: Read feedback and group it by theme. Decide what is worth changing now and what can wait until after launch.
  • Days 8 to 12: Ship one meaningful update based on feedback, if you have something worth shipping. Keep changes small so you don't introduce new bugs late.
  • Days 12 to 14: Stop changing things. Review your feedback notes and draft your production access answers while the details are fresh.

Be careful with updates. Pushing a new build is generally fine, but check Play Console to make sure your testers stay opted in and the counter hasn't reset. If you want daily visibility into whether testers are actually opening the app, TesterMob offers an optional Android SDK (an .aar file) that shows daily tester activity in your developer dashboard. You can read about the setup on the developer page.

Phase 5: Apply for production access (day 14 or after)

When the 14 days are complete, Play Console lets you apply for production access. You'll be asked questions about your testing, such as how you recruited testers, what feedback you received and what you changed.

Answer these honestly and specifically. Your notes from Phase 4 make this easy. Vague answers are harder to take seriously than a short, concrete account of what testers found and what you fixed.

Then wait. Google's review time varies, so don't schedule a marketing launch for the day after you apply. Build in some slack, and check Play Console Help for the current expected timeframe.

Phase 6: Prepare the production release (while you wait)

Use the waiting time productively:

  • Finish your store listing: screenshots, feature graphic and descriptions.
  • Double-check the Data Safety form against what your app actually does.
  • Review Android vitals for crashes and ANRs from the test period.
  • Decide whether you'll use a staged rollout for your first release.

Phase 7: Release to production

Once access is granted, create a production release, upload your AAB, add release notes and submit it for review. Reviews of a first production release can also take some time, so allow for that in your plan.

A staged rollout, where you release to a small percentage of users first, lets you catch problems before they reach everyone. It's a sensible default for a solo developer who can't monitor everything at once.

A sample calendar

Here is how the phases might look end to end. Treat these as planning guesses and adjust them to your situation.

  1. Weeks 1 to 2: Build, sign, draft the listing, complete the forms.
  2. Day 15 (start of week 3): Create the closed track, upload, share the opt-in link.
  3. Weeks 3 to 4: Closed test runs for 14 days. Collect feedback, ship one update.
  4. End of week 4: Apply for production access.
  5. Week 5 and beyond: Wait for review, finalize the listing, then release.

If a counter resets or a tester drops out, add days. Builds with crashes on launch cost you the most time, so the pre-launch work in Phase 1 is where you save it.

The short version

Do the preparation before the clock starts, recruit more testers than you need, use the 14 days to listen and fix, and keep notes for the production access questions. TesterMob isn't affiliated with Google, and nobody can promise approval. A tidy, honest process is your best argument.

For more guides on individual steps, browse the blog.

Your 14 days start today.

Set up your closed test in minutes, or join as a tester and start earning.