Who Owns Your Code? IP, Accounts and the Handover Checklist

You paid for the app, so you own it. That is what most founders assume, and under U.S. law it is not automatically true. Who owns app source code depends on who wrote it, whether they were your employee, and what you both signed. Ownership of the code is also only half the story: the GitHub repository, cloud hosting, domain and app store listings are separate accounts, and whoever controls them controls your product in practice. This guide explains the rules in plain English, shows the common traps, and gives you a checklist to use before you pay a deposit and again at handover.

This is general information, not legal advice. For contracts that matter, have a lawyer review them.

What the law says, in plain English

Three parts of the U.S. Copyright Act matter here.

The author owns it first. Section 201(a): "Copyright in a work protected under this title vests initially in the author or authors of the work." The person who writes the code is the author unless an exception applies.

The work-made-for-hire exception. Section 101 defines a work made for hire in two ways. The first is "a work prepared by an employee within the scope of his or her employment." If your salaried employee writes code as part of their job, the company is the author.

The second covers specially commissioned works, but only if they fall into listed categories, such as a contribution to a collective work, part of a motion picture, a translation, a compilation, an instructional text, a test or an atlas, and only if the parties agree in a signed written instrument. Custom software is not on that list. That is why many lawyers do not rely on a "work for hire" clause alone for contractor-written software, and add an assignment.

Transfers must be in writing. Section 204(a): a transfer of copyright ownership "is not valid unless an instrument of conveyance, or a note or memorandum of the transfer, is in writing and signed by the owner of the rights conveyed." A handshake, an email saying "it's yours" or an invoice marked paid is not the same as a signed assignment.

What this means for you

The accounts problem

Legal ownership and practical control are different. Plenty of founders have had a signed contract and still been locked out, because the developer set up every account in their own name.

These are the accounts that make up your product:

• Code repository (for example, GitHub). Where the source code and its history live.
• Cloud and hosting (for example, Vercel, AWS, Supabase). Where the app runs and the data is stored.
• Domain registrar. Whoever controls the domain controls your website and email.
• Apple Developer account. $99 a year. The app listing, reviews and ratings live here.
• Google Play developer account. $25 one-time registration.
• Third-party services. Payments (Stripe), email sending, analytics, maps, push notifications.

Why moving accounts later is painful

It can be done, but it is slow and not everything comes with you.

App Store. Apple lets you transfer an app between developer accounts, but only if it meets all of Apple's transfer criteria, and the process requires the account holders on both sides to act. Some things do not transfer: Apple lists promo codes, Apple Pay merchant IDs and Xcode Cloud data among them. After a transfer, the original account keeps access to past sales data, and apps that share iCloud containers with other apps can lose access to that data.

Google Play. Google lets you transfer apps between developer accounts by request. Historical reports and test groups do not transfer, and you need to update integrated services like Firebase and AdMob. Google says its team reviews requests "within 2 business days."

GitHub. Repositories can be transferred by someone with admin access. Issues, pull requests, history, webhooks and deploy keys move with it, and "the original owner of the repository is added as a collaborator," so you should remove old access afterward.

All of this depends on the other person cooperating. If the relationship has gone bad, cooperation is exactly what you will not get. The fix is simple: create the accounts yourself, in your company's name, at the start, and invite the developer as a user.

The no-code and platform question

No-code tools raise a different ownership question. Bubble's documentation states: "Bubble apps can only be run on the Bubble platform; there's no way of exporting your application as code. If you decide to move off the Bubble platform, you'll have to rebuild the application logic."

You can own your data and your design, but the working app only exists on that platform. That is a reasonable trade for a prototype or an internal tool. It is worth knowing before you build a company on it, because buyers and investors in a software business will ask what you actually own. See how to build an app without knowing how to code for the full picture.

Common traps

1. The developer's personal GitHub. The code lives in their account. You have "access" but not ownership of the repository.
2. The agency's cloud account. Your app runs on their hosting bill. If you stop paying their retainer, they can switch it off.
3. The app listed under the developer's name. Your app's App Store page says it was published by someone else. Moving it later requires their cooperation and Apple's criteria.
4. Ownership "on final payment" with no end date. If the contract says you own everything only after the final invoice, a disputed last milestone can leave you with nothing.
5. Reused code with no license. Agencies often reuse internal components. That is fine if the contract gives you a perpetual license to use them.
6. Subcontractors. An agency may use freelancers. If those freelancers never assigned their work to the agency, the agency cannot fully assign it to you.
7. Credentials in someone's head. Passwords, API keys and signing certificates stored on one developer's laptop.

Contract clauses to ask for

Plain-English versions of what to look for. A lawyer can turn them into proper language.

• Assignment: the developer assigns all rights in the work product to you, in writing, as each part is paid for.
• Pre-existing materials: anything the developer brought in before the project stays theirs, but you get a perpetual, royalty-free license to use it in your product.
• Subcontractor assignments: anyone the developer uses has assigned their rights, so the chain is clean.
• Open-source disclosure: a list of open-source components and their licenses.
• Accounts: all production accounts are held in your name; the developer gets user access only.
• Handover: on request or at the end of the engagement, the developer delivers the code, credentials and documentation within a set number of days.

Worked example: the handover checklist

Use this checklist before the final payment of any build, and again whenever you change developers. Tick each item only when you have verified it yourself.

If you cannot tick an item, do not make the final payment until it is fixed. It is much easier to resolve while the relationship is friendly.

Before you hire: the three questions

Ask any developer or agency these before you sign:

1. "Will you set up the accounts in my name, or can I create them and invite you?"
2. "When does ownership of the code transfer to me, and is that in the contract in writing?"
3. "Do you use subcontractors, and have they assigned their work to you?"

Good builders answer all three without hesitation. For the rest of the list, see 12 questions to ask before hiring an app development company. If you are still choosing between a freelancer, agency, studio or no-code, see freelancer vs agency vs studio vs no-code.

How Ottomind can help

Ottomind is an AI lab and software studio. We build and run our own products, like Otticos for rental operations and Cammonly for threshold-based event ticketing, and we build products for clients through Ottomind Studio. On studio projects, you own your GitHub, cloud, domain and app-store accounts from day one, and the work is assigned to you as it is paid for, not at some final milestone. Each project gets a fixed price after a scoping call, with UX/UI design included; focused MVPs start from $25,000, with v1 targeted within about 4 weeks of scope sign-off and a 30-day warranty.

You can take the product in-house at launch or keep us on a monthly plan with no minimum term. The Studio page sets out how ownership works. One exception to note: on our Starter option, a $500-a-month rental of a Store web app, Ottomind owns the app until you buy it. Read the Starter terms if you are considering that route.