Web Development Company in Pune: Launching Your Business App on Google Play — Developer Account, Closed Testing, Target API Level and Review, Explained Before You Pay for the Build

Web Development Company in Pune: Launching Your Business App on Google Play — Developer Account, Closed Testing, Target API Level and Review, Explained Before You Pay for the Build

Launching a business app on Google Play takes more than a finished app: you need the right type of developer account, a closed test that meets Google's rules if your account is a personal one created after 13 November 2023, a current target API level, a completed Data safety form with a privacy policy, and time for review. A web development company in Pune that builds apps should walk you through these steps before development starts, because several of them take calendar time that no amount of coding speed can shorten. The most common surprise for first-time app owners is that "the app is ready" and "the app is live" are separated by weeks of account setup, testing and approvals.

This guide is for owners of clinics, schools, coaching classes, retail chains, NGOs and service businesses who have decided that they need an Android app and want to understand the launch process before signing a contract. It is based on Google's own Play Console help pages, which we cite at the end. Google changes these rules, so treat dates and numbers here as correct on the day we checked them and confirm them in your Play Console before you plan around them. If you are still deciding whether you need an app at all, read our comparison of a mobile app versus a website first.

The Launch Path in One View

Before the detail, here is the sequence a typical first launch follows.

1. Choose and create the right developer account type, in your business's name.
2. Build the app against a current target API level.
3. Test internally, then, if required, run a closed test for the required period.
4. Prepare the store listing, privacy policy and Data safety form.
5. Submit for review and wait.
6. Release to production, ideally in stages, and plan for updates.

The sections below explain each step and where the delays come from.

Step 1: Choose the Right Developer Account — Personal or Organization

Google Play offers two account types. According to Google's help page on account types, both have the same functionality and can monetise through a payments profile. A personal account suits students, hobbyists and amateur developers. An organization account is for commercial, industrial, professional or governmental activities, and Google says you should choose an organization account if you offer financial services, health apps, VpnService-based apps or government apps.

For almost every business reading this, the organization account is the correct and more honest choice. The app represents your company, so the developer name shown on the store should be your company's name, and the account should be owned by the company, not by an employee or by the agency building the app.

The D-U-N-S number

To create an organization account, Google states you "must have a D-U-N-S number", which Google Play uses to verify your identity. Google notes that applying through Dun & Bradstreet is free, and warns about third-party services that charge high fees for this registration. If your company does not yet have a D-U-N-S number, apply early. We cannot tell you how long it will take for your company, because that depends on the registry and on your documents, so build slack into your launch plan rather than assuming it is quick.

Who should own the account

This point is not in Google's help page; it is practical experience that any careful agency will repeat. Create the account with your company's email address, with your company as the legal owner, and add the agency as a user with the permissions it needs. If the agency creates the account in its own name "to save you time", you may find that you cannot move the app later without a transfer process, and you may be publishing under someone else's brand. Our handover and ownership checklist covers the same principle for websites, and it applies to app stores too.

Verification and identity details

Google links to separate pages describing the information you must supply and the verification that follows. Expect to provide business details, contact information and identity checks, and expect to keep them accurate afterwards. Do not leave this to the last week of the project.

Step 2: The Closed Testing Requirement for New Personal Accounts

This is the rule that catches most small developers by surprise. Google's help page states that personal accounts created after 13 November 2023 must "run a closed test for their app with a minimum of 12 testers who have been opted in continuously for at least 14 days" before they can apply for production access. Testers who leave and rejoin must reach 14 consecutive days to count.

What Google's page does not say, in the version we read, is whether the same requirement applies to organization accounts. Do not assume either way. Check the current wording in your own Play Console when you create the account, because the rules have been revised before and may change again. If you hold a personal account, plan for it: the 14 days are calendar days that start only when the 12 testers have opted in, and finding 12 reliable testers is often harder than it sounds.

What counts as a tester

Testers need a Google or Google Workspace account. They opt in through a link, and Google notes that the opt-in link appears only when the app's status is "Published" on that track. For closed tests using a Google Group, testers must join the group before opting in. Testers opt in once and stay opted in; leaving the test resets the clock for that person.

The three testing tracks

Google's testing documentation describes three tracks:

Two further details from Google's pages are worth knowing. A user opted into internal testing cannot receive open or closed test builds until they opt out of internal testing. And a Data safety form is not required for apps active only on the internal testing track, but it is required for apps on closed, open or production tracks.

How to run a closed test that is genuinely useful

Treating the test as a box to tick wastes the best chance you will have to find problems with real people. A better approach:

• Recruit by role, not just by number. Use staff from different departments, a few loyal customers, and a few people who are not technical. For an NGO, include a volunteer and a donor. For a clinic, include reception staff and a patient who is comfortable with phones.
• Cover different phones. Ask for testers on at least a few Android versions and screen sizes, including an older, cheaper phone. Many problems appear only on low-memory devices.
• Give testers tasks, not just a link. "Register, book an appointment, cancel it, and tell us what confused you" produces more than "please try the app".
• Collect feedback in one place. A shared sheet or a WhatsApp group with a simple template works; scattered voice notes do not.
• Fix and release updates during the test. Closed test participants receive new versions on the track, which lets you check that your update process works before launch.

Step 3: Build Against the Current Target API Level

Google requires new apps and updates to target a recent Android version. Per Google's help page on target API level requirements, from 31 August 2026 new apps and app updates must target Android 16 (API level 36) or higher, and developers can request an extension to 1 November 2026. The Android 15 (API level 35) requirement took effect on 31 August 2025. For existing apps, to stay available to new users on devices running a newer Android version than your target, your app must target Android 15 (API level 35) or higher. Permanently private apps restricted to a specific organisation and distributed internally are exempt.

What this means in practice:

• A new app must be built against the current requirement. Ask your developer, in writing, which target API level the build uses and whether it meets Google's current rule on the date of submission.
• An older app may be quietly losing reach. Per Google's page, apps targeting lower levels are only available on devices running the same or older Android versions. If you have an existing app built years ago and never updated, ask for an audit.
• This is a recurring cost. The target level rises roughly each year. Our article on mobile app maintenance cost explains why a launched app needs a yearly update budget, and this requirement is one of the reasons.

Google's other developer policies also change, including verification requirements for developers. We cover one of them in our article on Google's Android developer verification rules. Read it alongside this one, and confirm the current position on Google's pages.

Does the framework matter?

If your app is built with Flutter or React Native, the target level is set in the Android part of the project and is not a barrier, but it does require someone who knows how to update it. Our comparison of Flutter and React Native for Pune businesses explains the trade-offs. If you are considering a progressive web app instead, see our article on PWAs versus native apps, since a PWA avoids some store requirements, with its own limits.

Step 4: Privacy Policy and the Data Safety Form

Every app published on Google Play needs to be honest about what data it collects. Google's help page states: "All developers that have an app published on Google Play must complete the Data safety form." It applies to apps on closed, open or production testing tracks; apps active only on internal testing are exempt, as are system services and private apps. A privacy policy is "required to complete the Data safety form and have your data safety information shown to users", and this applies even if the app collects no user data.

What to do before you fill in the form

1. List every piece of data the app handles. Names, phone numbers, email addresses, location, photos, payment details, device identifiers, crash logs and analytics. Include data collected by third-party software inside the app, not just by your own code.
2. List every third-party SDK. Analytics, crash reporting, push notifications, maps, payment gateways and chat widgets each collect data. Ask your developer for the list. A form that omits an SDK's data collection is inaccurate even if you did not mean it to be.
3. Decide how long you keep data and who can delete it. Your privacy policy must say.
4. Write the privacy policy for the app itself. A page copied from a template that talks about "our website" is a weak answer. Publish it at a stable web address on your own site, and link it in the store listing. Our article on DPDP Act website compliance covers the Indian legal background for personal data; it is general information, not legal advice, so take professional advice on your own obligations.
5. Keep the form and the app in step. If a later update adds a new SDK, revisit the form.

Why this is a business decision, not a form

If your app collects health information, children's data, donor details or financial information, the privacy design is part of the product. An NGO app that collects donor details has the same duties as its website. Decide what to collect before the build, not after.

Step 5: The Store Listing

The listing is your shop window. Prepare it in parallel with development:

• Name and short description that say what the app does in plain words, in the language your customers use.
• Screenshots from real screens, not mock-ups that do not match the app. Mismatched screenshots are a common cause of rejection and a common cause of poor reviews.
• An icon and feature graphic that look right at small sizes.
• A support contact that someone actually checks. An unanswered support email shows up in reviews.
• Content rating and category answers completed honestly in the Play Console.

Write the listing text yourself, or at least approve it. An agency will often write a generic listing; one that sounds like your business converts better.

Step 6: Submit, Wait and Plan for Rejection

Google's help page on app review does not give a typical review time. It says review length varies by account and app, and that review times may be "up to seven days or longer in exceptional cases" for certain developer accounts that Google reviews more thoroughly. Updates to existing apps are generally "processed and published as soon as possible", although some apps face extended reviews. Google also offers managed publishing, which lets you control exactly when approved changes go live.

Plan accordingly:

• Submit earlier than you think you need to. If you are promising a launch date to customers or a donor campaign, leave several weeks of buffer, not days.
• Use managed publishing for a launch. This lets you approve the app, then publish at a time that suits your announcement.
• Expect that rejection is possible. Google says that if an update does not meet policy, you can fix and resubmit or appeal. Ask your agency who handles that and how quickly.
• Resolve errors before submitting. Google notes that an "Errors summary" in your release summary stops you from publishing until the errors are fixed; warnings do not block, but it recommends fixing them first.

A Worked Timeline (An Illustration, Not a Promise)

Imagine a Pune coaching class that wants an Android app for students to see timetables and notes. We deliberately do not give a number of weeks for the build, because that depends on the feature list. The launch-side tasks, in order, look like this:

1. Before development starts: the owner applies for a D-U-N-S number for the company if there is none, and starts the organization account registration.
2. During development: the agency builds against the current target API level, and the owner drafts the privacy policy and a list of data the app will collect.
3. When a first build exists: internal testing with the owner's staff, using the internal track.
4. When the app is stable: a closed test with students and teachers, run for at least as long as any requirement applies to the account, with fixes released during the test.
5. Before submission: the Data safety form and store listing are completed, using the SDK list from the developer.
6. Submission: the app is submitted with managed publishing, leaving a buffer before the announcement.
7. After approval: the owner publishes on the chosen day, and the agency monitors crash reports and reviews for the first fortnight.

The exact calendar will depend on your account type, your documents and the review. The point is to start steps 1, 2 and 5 early, because they are not on the developer's critical path and are therefore easy to forget.

What to Ask a Web Development Company in Pune Before Signing

1. Which developer account type will we use, and will it be in our company's name?
2. Do we already have a D-U-N-S number, and who is applying for it if not?
3. Which target API level will the build use, and who updates it each year?
4. If a closed-test requirement applies to our account, who recruits testers and who manages feedback?
5. Which third-party SDKs does the app include, and what data does each collect?
6. Who writes and hosts the privacy policy, and who completes the Data safety form?
7. Who owns the signing keys and the source code at handover?
8. What is included after launch: bug fixes, Android version updates, store policy changes?

Question 7 deserves special attention. The app's signing configuration and source code should be handed to you, so that you can move to another developer without losing the ability to update the same app listing.

Related: planning an iPhone version too? Read how to get a business app approved on the Apple App Store.

Frequently Asked Questions

Do I need a D-U-N-S number to publish an app on Google Play?

If you register as an organization, yes: Google's help page says you must have a D-U-N-S number to create an organization developer account, and that it is used to verify your identity. Applying through Dun & Bradstreet is free, according to Google, which also warns against third-party services that charge high fees for this registration.

How many testers do I need before launching on Google Play?

For personal developer accounts created after 13 November 2023, Google requires a closed test with at least 12 testers opted in continuously for at least 14 days before you can apply for production access. Google's page does not say whether this applies to organization accounts, so check your Play Console for the current rule on your account.

What is the target API level for a new Android app in 2026?

According to Google's help page, from 31 August 2026 new apps and app updates must target Android 16 (API level 36) or higher, with an extension available on request to 1 November 2026. Existing apps need to target Android 15 (API level 35) or higher to stay available to new users on newer devices. Confirm the current rule before you submit.

How long does Google Play take to review an app?

Google does not state a typical time. It says review times vary and may be up to seven days or longer in exceptional cases for some accounts. Submit with a buffer and use managed publishing so you control the go-live date.

Do I need a privacy policy if my app collects no data?

Yes. Google states that a privacy policy is required to complete the Data safety form, and that developers whose apps collect no user data must still complete the form and link to their privacy policy.

Sources

• Google Play Console Help, "Create and set up your app / developer account types": personal and organization account types, the D-U-N-S requirement, and the free Dun & Bradstreet application.
• Google Play Console Help, app testing requirements for new personal developer accounts: the closed test with at least 12 testers opted in for 14 continuous days, for accounts created after 13 November 2023. The page we read did not say whether organization accounts are covered.
• Google Play Console Help, "Set up an open, closed, or internal test": tester limits and how testers join.
• Google Play Console Help, target API level requirements: Android 16 (API level 36) for new apps and updates from 31 August 2026, the extension to 1 November 2026, and the Android 15 (API level 35) condition for existing apps.
• Google Play Console Help, "Provide information for Google Play's Data safety section": who must complete the form, the exemption for internal-testing-only apps, and the privacy policy requirement.
• Google Play Console Help, "Understand the Google Play app review process": review time language, managed publishing, and rejection and appeal options.
• The timeline example is an illustration created for this article, not a client result. We give no build durations or cost figures because they depend on your feature list; our team confirms scope and pricing after a discussion.
• Google updates these pages. Dates and numbers above were read in October 2026; verify them in your Play Console before planning a launch.

About the author and next step

This guide was written by the web and app development team at Govindani Infotech, a website design and development company at 2nd Floor, Landmark Plaza, 206 Satara Road, Parvati Paytha, Pune 411009. If you are planning an app and want the launch steps mapped out before you commit to a build, see our website creation service, our AI automation service for workflows behind your app, or contact us on 092019 58274. Scope and pricing are confirmed by the team after discussing your requirements.