When Hiring an Android App Company Who Should Own the Publishing Account and Signing Key?

Why should publishing and technical ownership stay in-house?

The core principle is that commercial and operational control of the app should remain with the client company. A development vendor can build the product, prepare it for release, and manage versions, but tying the publishing account, source code, and critical access exclusively to the vendor's personal or corporate accounts makes a future transition unnecessarily difficult. The purpose is not to distrust the agency; it is to manage the app as a corporate asset that does not depend on a single service provider.

Separate ownership from operational authority

Owning the account and performing day-to-day release operations are different responsibilities. The company can retain ownership of accounts and assets while granting the development team the permissions required for its work. This approach makes it possible to evaluate the governance model alongside technical capability when comparing mobile app companies. Even if the vendor changes, the core digital assets remain under the organization's control.

• Define corporate control of the Google Play developer account.
• State who owns the source code repository in the contract.
• Treat signing access and publishing access as separate responsibilities.
• Create external service accounts under company control whenever practical.
• Limit vendor access according to its actual project role.

Programs must be written for people to read. - Harold Abelson and Gerald Jay Sussman

Which Google Play account should publish the application?

For a corporate Android project, the preferred model is to publish the app from a Play Console account controlled by the client company. Google Play Console provides different access levels such as account owner, administrator, and user, so a development vendor does not need to own the account in order to publish the app. The vendor can be invited with the permissions required for its role. Google's current help documentation likewise distinguishes the account owner from other access levels.

When does publishing from the vendor's account create risk?

If the app exists only inside the agency's developer account, operational dependency can arise. If the company later builds an internal team, moves to another software vendor, or goes through a corporate restructuring, account or app ownership may need to be transferred separately. Google Play provides formal processes for transferring developer account ownership and for moving an app between accounts, but choosing the right account structure at the purchasing stage reduces the need for a later transfer.

• State in the proposal which developer account will publish the app.
• Plan for the account owner to be a responsible person or structure within the company.
• Define the vendor's access level according to its duties.
• Avoid critical ownership structures that depend on personal email accounts.
• Define an access-removal procedure for a future vendor change.

How should Android signing key management be structured?

The signing setup should be documented and auditable so the application can continue to receive future updates. When Play App Signing is used, Google Play manages the app signing key used to sign the applications distributed to end users, while the developer side uses a separate upload key to authenticate the package submitted to Play Console. Treating these two keys as if they were the same can create serious ambiguity in proposal documents and handover procedures.

Which signing information should the company control?

Receiving only a keystore file is not enough. The documentation should explain what each key is used for, where it is stored, who is authorized to access it, which services use the certificate fingerprints, and what process will be followed if a key change becomes necessary. If Firebase, mapping services, authentication systems, or API providers depend on signing certificate information, those dependencies should appear explicitly in the technical handover list.

• Record whether Play App Signing is enabled.
• Distinguish the app signing key from the upload key.
• Assign responsibility for secure storage of the upload key.
• List every service that uses signing certificate fingerprints.
• Document key renewal and access-loss scenarios.
• Avoid arrangements where one person alone knows the password or file location.

How should application access be granted to the vendor?

Instead of transferring ownership to the development company, grant controlled access that is sufficient for the work it needs to perform. Because Play Console can separate access to the entire account from access to specific apps, responsibilities such as publishing, testing, store content management, or reporting can be authorized according to actual need. This lets the project team continue operating without the company surrendering control of critical accounts. Google's user and permission model explicitly supports both account-level and app-level access.

Why does least-privilege access matter?

Giving an agency unnecessarily broad access creates risk, while giving it insufficient permissions can disrupt operations. Before contracting, map which team role needs access to which system. The same approach should cover the source code repository, CI/CD platform, cloud account, analytics, notification infrastructure, and third-party API consoles. The guide on questions to ask about enterprise mobile app security provides a complementary framework for evaluating the security side of this access model.

• Identify owners, administrators, and operational users for each system.
• Use individual authorization instead of one shared password.
• Make it possible to remove access quickly when team members leave.
• Separate production and testing permissions where appropriate.
• Make multi-factor authentication a corporate process for critical accounts.

When should source code and service access be delivered?

Source code delivery should not be treated as a ZIP archive handed over only at the end of the project. A more sustainable model is to host the repository from the start in an organization controlled by the client company whenever practical and grant the development vendor project access. If that is not possible, the contract should define complete repository transfer, version history, dependencies, and configuration documentation at specific milestones. This prevents technical handover from becoming an unclear item first examined only after final payment.

The delivery list should include more than source code

When a new team takes over the application, it needs the working development environment, service configurations, and release procedure in addition to the code. For that reason, delivery criteria should be planned from the beginning when reviewing the enterprise mobile app development process. Cloud services, notification infrastructure, analytics accounts, API key management locations, environment variables, and application packaging steps should all be part of the handover documentation.

• Include the complete source repository and version history in the handover.
• Document development, testing, and production configurations separately.
• List ownership and access for third-party service accounts.
• Record dependencies and environment requirements needed for builds.
• Transfer access to CI/CD or automated release processes.
• Require technical documentation to match the current application version.

How should the release process be documented and tested?

A good handover document should allow a new developer to create a test build and prepare the store package without having to guess undocumented steps. It should explain the development tools in use, the application package identifier, build variants, environment variables, signing steps, and the order of actions required for store upload. Documentation alone is not sufficient; before handover, a technical person from the client side or someone previously uninvolved in the project should be able to follow the instructions and reproduce a build.

Make the release workflow repeatable

A release process that depends on one developer's computer or remembered commands creates operational risk. Wherever practical, build and deployment steps should be standardized, permissions should be centrally managed, and release notes should be recorded. Treating the release architecture as a delivery requirement while planning the mobile app development process makes subsequent updates more predictable and reduces the knowledge gap when personnel or vendors change.

• Document build commands and required tool versions.
• Explain the differences between testing and production configurations.
• Describe step by step how the store package is created.
• Standardize version numbering and release-note management.
• Add a pre-release checklist to the handover documentation.
• Perform an independent rebuild test before final handover.

Can a new team publish updates after changing vendors?

If ownership and handover are structured correctly, a new team should be able to continue development and publish updates. The company needs control of Play Console, the current source code, build information, upload key access, and the service accounts connected to the application. For projects enrolled in Play App Signing, the app signing key is managed by Google Play, so the new team's core requirements are the correct account permissions and a valid upload process.

Rehearse the handover scenario before signing the contract

Ask candidate vendors, “If we moved to another team today, exactly which assets would you deliver so they could publish the next update?” A useful answer should go well beyond “we will provide the source code.” Required accounts, keys, configurations, store permissions, and technical documentation should be defined together. When actual account ownership must change, Google Play's official ownership transfer workflow should be used rather than informal transfer methods.

• Define how the new team will receive Play Console access.
• Keep a complete current copy of the source code under company control.
• Plan access to the upload key and required secrets.
• Document how administrator changes are handled in external services.
• Create a checklist for removing the previous vendor's access after handover.

Are store operations and future releases included in the quote?

Initial development, first store publication, technical responses to store feedback, later releases, and ongoing maintenance are not the same service item. One proposal may cover only application development, while another may include the first publishing process, corrections required after technical or policy feedback, and a defined support period. Before comparing price, ask every candidate in writing which publishing responsibilities are included using the same scenario.

Read the Android maintenance proposal as a separate scope

Maintenance can include operating system compatibility work, dependency updates, bug fixes, security improvements, adaptation to store requirements, and new feature development. These items should not automatically be assumed to be part of the initial project scope. When comparing mobile app proposals by scope, contract, and ownership, separating post-release services into explicit line items creates a clearer basis for commercial evaluation.

• Ask whether the first Play Console release is included.
• Define the scope of fixes required after store feedback.
• Clarify how future releases will be requested and commercially scoped.
• Separate maintenance from new feature development.
• Distinguish urgent defect response from normal update work.
• Add technical handover obligations for the end of the support period.

Which ownership criteria should guide vendor selection?

The most useful comparison method is to give every candidate the same publishing and handover scenario and request a written response. Add questions such as “Which account will publish the app, how will signing be structured, when will source code be delivered, can another team publish updates, and what post-release services are included?” to the commercial proposal process. This makes the actual operational scope behind a lower or higher price much easier to see.

Look for measurable handover clauses in the contract

Instead of broad wording such as “all access will be delivered,” list the specific accounts, roles, technical files, and documents that must be transferred. If the application is intended to become a long-lived corporate digital asset, publishing account ownership and technical handover should be as concrete as the project's acceptance criteria. A well-structured proposal describes not only how the app will be built, but also how another qualified team can continue operating it through a reasonable transition.

• Compare whether the publishing account remains under company control.
• Make signing and key-management documentation a proposal requirement.
• Define the timing of source code and service access delivery.
• Test the vendor-change update scenario in writing.
• Evaluate first release, future versions, and maintenance separately.
• Define access removal and handover procedures for contract termination.