Publishing an App on Play Store Solo: Real Cost, Real Timeline, Every Wall I Hit

AI makes building an app fast. Publishing it is a different story.

I built and published an Android app, T Wala English, using AI coding tools. Building took days. Publishing took months.

Here is the real cost, the real timeline, and every wall I hit.

What It Costs to Start

• Google Play developer account: $25, paid once, no renewal.
• Apple charges $99 every year instead.
• That is why most solo developers start with Android.

After that $25, the real cost is time, not money.

The Stack I Used

• GitHub Copilot – AI coding assistant, the only paid tool.
• VS Code – free code editor.
• Expo CLI – free, makes React Native easy, updates your phone instantly.
• Expo EAS Build – free tier, builds the APK in the cloud.
• GitHub – free, stores the code and triggers builds automatically.
• Google Play Console – the $25 account, where the real work happens.
• AdMob and AdSense – both free, and you need both.

The same lean-stack approach works for no-code tools for freelancers and AI automation workflows: fewer tools, wired together well.

With this stack, building the app was fast. Publishing it was not.

The Biggest Wall: 12 Testers, 14 Days

• Personal accounts created after November 13, 2023 must run a closed test.
• You need 12 testers, opted in (installed), for 14 continuous days.
• Google lowered this from 20 testers in December 2024. Many guides still say 20.
• Organization accounts are exempt from this rule entirely.
• Do not use fake accounts to hit the number. It risks permanent account suspension.

I found 12 real testers and waited two weeks.

Legal Requirements Before You Publish

• A live privacy policy: a real URL, accurate about what data your app collects (ads and analytics count as data collection).
• Play Console declarations: data safety form, content rating, target audience, ads disclosure.

Getting these wrong is one of the most common rejection reasons.

Ads Took Longer Than Building the App

• AdMob needs AdSense too. AdMob links to AdSense for payments, so you go through two approvals, not one.
• Expo cannot preview ads. Ad code only works in a full build, tested on a real phone.

Every ad change meant: build, wait, install, check, repeat. This step took longer than everything else combined.

What Actually Helped: One Extra Developer

I hired one junior developer to work alongside me. Not a team, just one extra person.

While one build was running, the other person worked on the next fix. This cut the waiting time significantly, and helped avoid the fatigue of watching build logs alone.

Same logic as reducing manual work using AI: find the real bottleneck, then fix that specific thing.

Updates Bring the Same Two Traps

• Any change to data collection (like adding ads) means updating your data safety declaration.
• Your privacy policy must match that declaration, or you risk rejection.

Once I expected this, updates were fast: build, check, ship.

The Simple Workflow Now

Code in VS Code → push to GitHub → Expo EAS builds automatically → test on a real phone with ads live → publish via Play Console.

Next step: turn ads off in development builds and on only for production, to cut rebuild time further.

Where the App Stands Today

T Wala English is live with ads, a working UI, and a tag and revision system. Next up: a real AI feature, a proper backend, and a senior developer review before scaling.

Does AI Actually Help With Publishing an App?

Yes, but only with the build. AI did not speed up the 14-day tester wait, AdSense or AdMob approval, data safety declarations, privacy policy compliance, or ad rendering bugs.

Websites are fast end to end. Apps have a review process, a compliance layer, and a native build step that AI cannot skip.

Every Stage at a Glance

Stage	Cost	Time	AI Help
Play Console setup	$25 one time	~1 day	None
Building the app	Copilot subscription	Days	High
Closed testing	Free	14 days, 12 testers	None
Privacy policy	Free	Half a day	Some
Play Console declarations	Free	A few hours per release	None
AdSense / AdMob approval	Free	Days to weeks	None
Ad implementation	Free	Longest stage	Partial
Second update	Free	Fast, once you know the rules	Some

If you are starting today:

• Register as an organization account if you can. It skips the 12-tester rule.
• Get your privacy policy live early.
• Line up your 12 testers before the app is finished.

Frequently Asked Questions

How much does it cost to publish an app on the Play Store?
$25 one time. No annual renewal. Publishing itself is free.

How many testers do I need for Google Play?
12 testers, opted in for 14 continuous days, for personal accounts created after November 13, 2023. Organization accounts are exempt.

Do I need AdSense to use AdMob?
Yes. AdMob links to AdSense for payments, so you go through two approvals.

Can I test AdMob ads in Expo Go?
No. You need a full build installed on a real device to see ads render.

Can I publish an app without coding experience?
Building is achievable with AI help. Publishing still requires understanding privacy policy and data safety rules.

How long does it take to publish an app solo?
Building can take days. Budget four to eight weeks end to end, including the 14-day test period, review cycles, and ad approvals.

The Problems You Discover Only When You Are Almost Ready to Launch

The surprising part of publishing an app solo is that the final 10% can take more time than the first 90%.

The code may work.

The APK may install.

The UI may look finished.

And you can still have a list of things to fix before Google Play is ready to accept the app for production.

That is why I now treat publishing as a separate project from development.

The app is one project.

Getting the app safely through testing, declarations, review and production release is another.

Build for the Reviewer, Not Just Yourself

One mistake solo developers make is testing only the happy path.

You open the app, tap the main button, everything works, and you decide it is ready.

A reviewer does not know your preferred path through the application.

If the app requires an account, special access, a particular sequence of actions or test credentials, those details need to be available to Google Play during review. Google specifically asks developers to provide the resources necessary for reviewers to access restricted functionality.

Before submitting, I would test the app as if I had never seen it before.

Install the production-style build.

Open it from a clean device.

Check the first screen.

Try every important button.

Test the back button.

Test without an internet connection where applicable.

Test the login flow.

Test empty states.

Test incorrect input.

Test permissions.

Test ads.

Then ask a second person to use the app without explaining anything.

The places where they get confused are exactly the places a solo developer can miss because they already know how the app works.

Do Not Treat Play Console Forms as Administrative Work

The Play Console forms are not something to complete quickly at the end.

They describe what your application does, who it is designed for and how it handles user data.

Google’s App content documentation specifically covers privacy policy information, advertising declarations, target audience, content ratings, app access instructions and other policy-related disclosures.

That means the information in your app, privacy policy and Play Console should tell the same story.

If your application uses an advertising SDK, analytics SDK or another third-party service, understand what data that service processes before completing your declarations.

Do not guess.

Check the documentation for the SDKs you actually installed and keep a simple inventory.

For example:

• Advertising SDK
• Analytics SDK
• Authentication provider
• Crash reporting
• Push notifications
• Location services
• Camera or microphone access
• Storage or media access
• Any AI API or external service

This list becomes extremely useful when completing Data safety information.

Your Privacy Policy Should Describe the Real App

A privacy policy copied from a generic generator is not automatically a good privacy policy.

The important question is whether it accurately describes your application.

Google’s guidance says that privacy information should comprehensively explain relevant collection, use and sharing of user data, and certain apps must provide an active privacy-policy URL both on the store listing and within the app.

So build the policy around the actual implementation.

If you added analytics after writing the policy, update the policy.

If you added advertising, check the policy.

If you added login, check the policy.

If you introduced an AI API that processes user-submitted information, check the policy again.

The privacy policy should follow the product, not the other way around.

The Tester Requirement Is Not Just a Number

The current Google Play requirement for new personal developer accounts created after November 13, 2023 is a closed test with at least 12 testers continuously opted in for at least 14 days before applying for production access.

But there is another important detail.

The objective is not simply to collect twelve email addresses.

Google’s guidance tells developers to give testers clear instructions, collect meaningful feedback and encourage them to use different parts of the application. Google can also require additional testing if tester engagement is insufficient.

That changed how I think about beta testing.

Instead of asking:

“Can twelve people install this?”

Ask:

“Can twelve people actually use this and tell me what is broken?”

Give testers specific tasks.

Try the main feature.

Try an unusual input.

Turn the network off.

Close and reopen the app.

Test on different Android devices.

Report confusing screens.

Report crashes.

Report slow loading.

That produces information you can actually use.

Keep a Release Checklist

The simplest improvement I made was creating a checklist instead of relying on memory.

Before every production release, I check:

• Version name and version code
• Production build configuration
• App icon and store graphics
• App description
• Screenshots
• Privacy policy URL
• Data safety information
• Target audience
• Content rating
• Ads declaration
• Login credentials or reviewer access instructions
• Permissions
• Third-party SDKs
• Main user flows
• Ad rendering
• Crash-free startup
• Offline behaviour where relevant
• Real-device testing
• Release notes

Google’s own release guidance emphasizes accurate app information, privacy policy and Data safety requirements, reviewer access, and a stable user experience before submission.

A checklist sounds boring.

It is also much cheaper than discovering the same missing item during review.

Version Numbers Become Important Very Quickly

When you are building alone, it is tempting to think of every build as simply “the latest version.”

Do not.

Treat every release as a traceable version.

For example:

1.0.0 — first production release

1.0.1 — bug fix

1.1.0 — new feature

That is not a rule you must follow exactly; it is a system for keeping yourself organized.

More importantly, keep notes about what changed between builds.

When something breaks after an update, you want to know what changed.

This becomes especially useful when you are using AI coding tools. AI can make a change that solves one problem while quietly affecting another part of the application.

A clean version history gives you somewhere to go back to.

Test the Production Build, Not Just the Development Build

This is one of the easiest traps to fall into.

Your development environment may behave differently from the build that users actually install.

Ads may behave differently.

Environment variables may differ.

API keys may be configured differently.

Debug logging may hide a problem.

A development-only permission or dependency may behave differently in production.

That is why the final testing cycle should use the same type of build configuration you intend to distribute.

Android’s release preparation guidance also emphasizes configuring, building and testing the release version before distribution.

For a solo developer, this distinction matters because there is nobody else sitting between development and release to catch the difference.

You are the entire release department.

Watch What Happens After Launch

Publishing is not the finish line.

It is the beginning of the useful data.

After launch, watch:

• Crashes
• User retention
• Uninstall behaviour
• Ratings and reviews
• Store listing performance
• Ad performance
• API errors
• Server costs
• Support requests

Play Console provides dashboards and metrics that can help developers understand app performance after release.

The first production version should therefore be treated as a measurement system.

You are not trying to prove that the app is perfect.

You are trying to discover what real users do differently from your expectations.

The First Version Should Be Smaller Than You Think

This is probably the biggest lesson I took from the process.

When AI makes development faster, it becomes dangerously easy to keep adding features.

“I can build that too.”

Then:

“I can add an AI assistant.”

Then:

“I can add a social feature.”

Then:

“I can add subscriptions.”

Then:

“I can add five more settings.”

Suddenly your first release has ten systems to test instead of two.

AI reduces the cost of writing code.

It does not reduce the cost of maintaining complexity.

Every additional feature can create another UI state, another permission, another API dependency, another privacy consideration and another possible failure.

For a solo developer, simplicity is not a limitation.

It is a release strategy.

What I Would Do Differently Next Time

If I started another Android app tomorrow, I would move several publishing tasks much earlier.

First, I would create the Play Console account before the app was finished.

Second, I would publish the privacy policy while development was still underway.

Third, I would identify the SDKs and data flows before completing the Data safety section.

Fourth, I would recruit potential testers before the final build.

Fifth, I would test advertising much earlier if the business model depended on ads.

And sixth, I would maintain a release checklist from version 0.1 rather than creating one after the first problem.

The important lesson is that publishing should not be treated as the final button you press after development.

It should be part of the product plan from the beginning.

The Real Cost of Going Solo

The $25 developer registration fee is almost irrelevant compared with the real investment.

The real cost is coordination.

You are the developer.

You are the tester.

You are the product manager.

You are the release manager.

You are responsible for privacy documentation.

You are responsible for Play Console declarations.

You are responsible for monitoring the application after launch.

AI can reduce the amount of manual coding involved in some of those jobs.

It cannot remove the responsibility.

That is the difference I would keep in mind if I were starting again.

Building an app with AI is increasingly accessible.

Shipping a reliable app is still an engineering and product process.

And once you understand that distinction, the Play Store stops looking like a mysterious final wall.

It becomes another workflow — one that can be planned, measured and improved.

Final Thoughts

AI changed what a solo developer can build. It has not changed what a solo developer has to survive to ship.

I write about the systems behind this kind of work, including using AI for business growth. Building an app solo right now? Tell me which stage you are stuck on in the comments.