A business pays an agency to build an app. A year later it wants to switch agencies, or sell the company, or simply update the app without the original team. That is when it finds out who owns what. Often the answer is "mostly you, except the parts that matter."
An app is four things that are owned separately: the source code, the domain, the Apple developer account, and the Google Play developer account. Each one has its own rules, and none of them follow automatically from "we paid for it." This post goes through each one using the official sources, and ends with the setup we recommend to every client before work starts.
This is not legal advice. The copyright section is US law, and other countries treat it differently. Show your contract to a lawyer.
The code: paying for it is not owning it
Under US law, copyright "vests initially in the author" of a work, according to section 201 of the Copyright Act. The author is normally the person who wrote it. If an outside agency or freelancer wrote your code, they start out as the owner, not you.
The exception people reach for is "work made for hire." The Copyright Office's Circular 30 says there are exactly two ways to get one. The first is work an employee creates as part of their regular duties. The second is a commissioned work, which only qualifies if it falls into one of nine listed categories, such as a contribution to a collective work, a translation, or a compilation, and both parties sign a written agreement saying it is a work made for hire. Circular 30 is blunt: "If a work fails to satisfy any of these requirements, it is not a work made for hire."
Custom software is not on that list of nine. Whether a given app could fit one of the categories is a question for a lawyer, and that is the point: you do not want your ownership to depend on it. The reliable route is a transfer. Section 204 says a transfer of copyright ownership "is not valid unless" it is in writing and signed by the owner.
Our position: every development contract should include a signed written assignment of copyright in the delivered code to the client, whether or not it also says "work made for hire." Libraries and frameworks the agency did not write stay under their own licenses, and the contract should say so. And ownership on paper is worth little without the repository itself, so the code should live in a repository the client owns from the first commit.
The Apple account: the name on the store
The Apple Developer Program enrolls individuals or organizations. For an individual, "your personal legal name will be listed as the seller on the App Store." For an organization, the legal entity name is the seller, and Apple asks for a D-U-N-S number to verify it. The person enrolling must have legal authority to bind the organization.
If the agency publishes your app under its own account, the agency is the seller on your listing. Moving it later is possible but not clean. An app transfer is started by one account's Account Holder and accepted by the other's. The app keeps its reviews, ratings, and users. But the criteria block transfers while a version is waiting for or in review, and the overview lists what breaks: keychain sharing stops working after the next update, so "users must re-login once"; an Apple Pay merchant ID does not move; apps using Sign in with Apple need a transfer identifier generated for each user.
The Play account: the key matters more than the listing
On Google Play, a transfer moves users, statistics, ratings, reviews, and subscriptions to the new account. It does not move earnings and bulk export reports, promotions, or test groups. Both accounts must be registered and active, the request needs the registration transaction ID of both accounts, and support reviews requests within two business days.
The part that is hard to recover is the signing key. With Play App Signing, Google holds the key that signs what users install, and the developer holds a separate upload key. If the upload key is lost, "Google can reset it for you." But the app signing key "cannot be reset if you manage it yourself and lose it." If an agency set up the app with its own key and kept it, that key needs to be handed over or the app moved to Play App Signing. Our Android verification post covers why this now matters outside Play too.
The domain: a 60-day wait if you get it wrong
Domains have a registrant, the Registered Name Holder. Under ICANN's Transfer Policy, the Registered Name Holder and the Administrative Contact can approve or deny a transfer, and in a dispute the Registered Name Holder's authority wins. If the agency registered your domain in its own name, the agency is the one with that authority.
Fixing it afterwards costs time. The policy lets a registrar deny a transfer to another registrar within 60 days of a domain's creation or of a previous transfer. A registrar may also apply a 60-day transfer lock after a change of registrant, unless the registrant opted out first. If you plan to change the registrant and move registrars, those 60 days come after the change.
The setup we recommend
The pattern is the same for all four: the client creates and owns the account, and the agency gets access as a team member. Both Apple and Google let an account add team members. Access can be removed in a minute. Ownership can take weeks to move.
If you are about to start a project, set this up first. If your app already exists and any line points to someone else, fix that line before the relationship needs it. This is how we think every custom software engagement should start. If you want a second opinion on your current setup, send us the list.
// sources
// next step
We work this way on client projects too.
Tell us what you are making. We reply with a plan, a timeline, and a price.
