Own Your App Before Someone Else Builds It
The accounts, identifiers, credentials, and data a founder must control from day one.
On This Page
A contractor can build your app. They should not own your product.
Mobile projects create a surprising number of durable assets: store accounts, signing credentials, identifiers, domains, backend projects, analytics, payment accounts, and source code. Losing control of one can delay a release; losing several can make the product impossible to transfer.
The company owns the asset. Named people receive roles. Contractors receive time-bounded access. Nobody needs the founder's password.
Map ownership in three layers
The company name on store, billing, domain, and vendor records.
At least two trusted people who can restore access and change roles.
Agency or developer with only the permissions and duration required.
The company-owned checklist
Create every item in an account controlled by the founder's company:
- Apple Developer Program membership.
- Google Play Console account.
- iOS bundle identifier and Android package name.
- Certificates, provisioning profiles, and signing keys.
- Domain and DNS account.
- Backend and database projects.
- Analytics and crash-reporting accounts.
- Source repository and CI/CD access.
- Stripe and store-billing accounts.
Invite agencies and freelancers with the narrowest role they need. Do not share a founder password.
| Asset | Company must control | Contractor usually needs |
|---|---|---|
| Store accounts | Legal entity, agreements, billing, recovery | App manager or developer role |
| Source repository | Organization ownership, admin, backups | Write access to assigned repositories |
| Cloud/backend | Billing, production ownership, audit access | Developer access; production changes through review |
| Domain/DNS | Registrar, recovery email, renewal payment | Specific DNS change or delegated zone |
| Payments | Legal entity, bank, tax, disputes | Developer/sandbox access; rarely bank settings |
| Signing | Secure custody and recovery process | CI signing or limited certificate access |
“We will create the Apple account for you,” “the source stays in our GitHub,” “production uses our Firebase project,” or “we will transfer everything later.” Transfer later is possible in some systems, awkward in others, and dangerous everywhere. Start clean.
Identifiers deserve special care
Your bundle ID and package name connect updates to the existing store listing. Changing them usually creates a new app identity, separating you from existing installs, reviews, and history.
Choose a company-owned namespace, document it, and make sure the production identifier is not tied to an agency's brand.
Understand signing without becoming a cryptographer
Signing proves that an update came from an authorized publisher. Think of the store listing as a locked mailbox and the signing identity as the key. Protecting the key matters; so does documenting how the build system uses it.
- Keep recovery options under company-controlled email and phone numbers.
- Prefer managed, audited CI credentials over files passed through chat.
- Separate development, staging, and production environments.
- Record expiration and renewal responsibilities.
- Test that a second authorized admin can perform a release.
Plan the account lifecycle
Account creation is only the beginning. Specify:
- Sign-up and email verification.
- Password reset and social-login recovery.
- Session expiration and revocation.
- Subscription cancellation and purchase restoration.
- In-app account deletion.
- Data export and deletion.
If users can create accounts, Apple expects them to be able to initiate deletion inside the app. Treat deletion as a product flow and backend operation, not a support-ticket workaround.
Create a handoff packet
Keep a secure inventory of the owner, admin URL, recovery contact, billing contact, identifier, and renewal date for every service. Add architecture notes, release instructions, environment names, and a list of third-party SDKs.
Never put passwords or raw secrets in the repository or the inventory document. Use a password manager and secret storage.
Contractor exit test
Ask: if the current contractor disappeared tomorrow, could a new team build, sign, submit, operate, and bill for the app?
If the answer is no, fix ownership before adding features.
A practical access review
Run this review at launch, quarterly, and whenever a contractor leaves:
- Two internal admins can sign in and recover every critical account.
- Company billing and recovery contacts are current.
- Former team members and unused tokens are removed.
- Production secrets have named owners and rotation dates.
- The current source can produce the store build.
- Identifiers, certificates, and release steps are documented.
- Backups have been restored in a test—not merely configured.
Scenario: the agency disappears Friday
On Monday, a production login bug appears. A healthy ownership setup lets the company invite a new engineer, reproduce the build, access crash reports, patch the backend, sign a client update, and answer store reviewers. The goal is not to eliminate disruption. It is to prevent loss of control from turning disruption into paralysis.
The takeaway
Ownership is architecture. Company-controlled accounts and documented access paths turn a contractor relationship into a replaceable service instead of a permanent dependency.