Ownership and access
Who owns each account at the start of a project, how people get access, and how each account is handed to the client at the end. Read it on day 0, and again at handover.
How it works
Our default: Synterra creates and owns the accounts, and transfers them at handover. It is faster to set up, we control security from day one, and the client does not need an engineer to click through consoles.
The exception is any account that sells or receives money. The legal entity on those accounts is the seller of record. Its name is shown to buyers, its bank account receives the payouts, and its tax forms are filed. That has to be the client, from the start.
The ownership table
Copy this into the project repo as OWNERSHIP.md and fill it on day 0.
| Account | Owner during the project | Synterra access | At handover |
|---|---|---|---|
| GitHub organisation | Synterra | Owners | Make a client person an owner, then remove ours |
| AWS organisation (management account) | Synterra | SSO admin | Move member accounts into the client's organisation |
| Domain and DNS | Synterra | Registrar admin | Registrar transfer to the client |
| Apple Developer account | Client's legal entity | Admin, App Manager | Remove our users |
| Google Play developer account | Client's legal entity | Admin | Remove our users |
| Stripe and payment gateways | Client's legal entity | Administrator | Remove our users |
| Email, push, crash reporting, analytics | Synterra | Owner | Transfer the project or workspace |
| AI providers | Synterra or client, by contract | Owner | Move keys to the client's account |
How access is given
- People are added to the organisation, then to teams, never as one-off collaborators on repos. Leaving the team removes all access.
- Least privilege per role. Developers get write on repos and SSO into dev and staging. Production access is a separate permission set, given to named people.
- Outsiders (a client's other vendor, an auditor) get read-only access to the specific repo or account, with an end date in the ownership table.
- Every human uses MFA. On AWS that means IAM Identity Center, not IAM users.
Transfer at handover
As of October 2026. Check each provider's current help page before you start, because the steps change.
| Account | How | Watch out for |
|---|---|---|
| GitHub org | Add the client's person as an owner, then remove ours. The org, repos, history and settings stay as they are | Packages and Actions secrets stay with the org. Remove our personal access tokens and deploy keys |
| AWS member accounts | Invite each account from the client's organisation and accept it. Since November 2025 an account can move directly between organisations (AWS announcement) | Delegated administrators, organisation-wide CloudTrail and SCPs belong to the old management account. Recreate them in the client's organisation first |
| AWS management account | Usually not transferred. The client creates their own organisation and receives the member accounts | Keep billing history exports before you close ours |
| Domains | Registrar transfer, or change the registrant at the same registrar | Unlock the domain, get the auth code, keep DNS in Route 53 so nothing moves |
| Apple app (if it ever lived in our account) | App transfer in App Store Connect (criteria) | Needs a released version, no pending review. Sign in with Apple users need transfer identifiers. Subscriptions need an app-specific shared secret. In-app product ids must not clash with the recipient's |
| Google Play app (if it ever lived in our account) | App transfer request in Play Console (checklist) | Test tracks do not move. Past orders and reports stay in the old account. Firebase must be relinked |
| Stripe | Created in the client's entity, so only users change | An account's country can never change (Stripe). A wrong-country account means a new account and a customer data copy |
Rules
Accounts that sell or receive money are created in the client's legal entity on day 0: Apple Developer, Google Play, Stripe and every payment gateway. We are admins on them, never the owner. Moving a live paid app or a merchant account later is slow, partial, and sometimes impossible.
The legal entity name must be identical everywhere: store accounts, merchant accounts, bank, privacy policy, terms. Reviews and KYC reject on exact-name mismatches.
No personal accounts. Not for GitHub repos, not for AWS, not for an API key "just to try".
Mistakes we made
- The store seller name had to change after launch when the client moved to a new legal entity. Both store accounts and the policy pages had to move together, and the developer membership had been invoiced to the wrong entity.
- Production had seven IAM users and none had MFA. Access had grown person by person. See AWS organisation.
Done when
-
OWNERSHIP.mdcommitted, signed off by the client. - Money accounts in the client's legal entity, with us as admins.
- Access through org teams and SSO, with MFA for everyone.
- Outsider access has an end date.
- Handover steps for every row are known before launch.