Who Owns the Source Code of My App? The Checklist We Use

Picture a cleaning company in Austin. Two years ago the owner paid a freelancer to build a booking app. It worked, customers used it, and nobody thought about the code again. Now she wants online tipping added. The freelancer takes a week to answer emails, so she calls an agency, and the first thing they ask for is "access to the repo and your App Store account." She has no idea what either one is. She paid for the app. Surely it's hers?

"Talk is cheap. Show me the code."

Linus Torvalds, linux-kernel mailing list, 2000

Maybe. Who owns the source code of your app depends on two things: what your contract says, and whose name is on the accounts the app lives in. The second one catches far more people than the first. We've taken over plenty of apps and sites from other developers in 9+ years and 1,000+ projects, and the code itself is rarely the hard part. The hard part is the Apple account in a stranger's name.

Here's how to find out where you stand, and what to ask for this week.

Who owns the source code of my app, legally?

In the US, you might not own it by default. That surprises most founders.

If an employee writes code as part of their job, the company owns it. A freelancer or an outside agency is different. The US Copyright Office explains that commissioned work only counts as "work made for hire" if it fits one of nine specific categories and both sides sign a written agreement saying so (Circular 30, Works Made for Hire). App code usually doesn't fit those categories neatly. So what you need is a clause in your contract that assigns the copyright to you, in writing, signed.

Open your contract and search for words like "assign", "intellectual property", "work product" or "ownership". You're looking for a sentence where the developer transfers all rights in the code to you, usually once the final invoice is paid. If you find one and you've paid, you most likely own the code. If the contract only gives you a "license" to use the app, you're renting it.

Two things often sit outside that clause:

• Pre-existing code. Agencies reuse their own starter kits and libraries. A fair contract gives you a permanent license to those parts so the app keeps working if you leave.
• Open-source libraries. Nobody owns these outright. They come with their own licenses, which are almost always fine for a business app.

This is general information, not legal advice. If real money or a dispute is involved, pay a lawyer for an hour to read the contract. It's cheap compared to rebuilding.

Owning the code and having it are two different things

Here's where most of the trouble starts. You can own every line of code on paper and still be stuck, because the app depends on accounts you can't log in to.

Your app lives in a lot of places. The code sits in a repository on GitHub or GitLab. The iPhone version is published through an Apple Developer account. The Android version goes through Google Play Console. The backend runs on AWS, Google Cloud, Firebase or a similar host. Then there's the domain, the email sender, the payment provider, the maps or SMS service, and the design files.

If those were set up under the developer's login, you have a copy of nothing. Moving an app between Apple Developer accounts is possible, but it takes both account holders to complete it. If the old developer won't cooperate, you may end up publishing a new app under a new listing and losing your reviews.

The ownership checklist we use

Before we build anything, we draw the client's system: what the app's main job is, what connects to what, and who maintains each piece. That drawing becomes this checklist. Go through it with your current developer, even if things are fine between you. Fine is the best time to do it.

If your name is on the invoice for something, it's probably safe. If the developer is paying for it and billing you, it isn't. That one question sorts most of the table.

What a proper handover looks like

When we finish a project, we hand over a short document that explains how the app is put together, so it isn't tied to us. It runs a few pages and covers where the code lives and how to run it, every outside service and which account it belongs to, how to publish a new version to each store, and anything odd a new developer would trip on.

A good handover means any competent team can pick the app up next month without calling the people who built it. We think every client should ask for that, from us or anyone else. It's also the best test of a developer: the ones who've done the work properly are happy to write it down.

When I took over the architecture of Rezaid Film Manager, a film-production SaaS that was already built and in testing, the first job was mapping what existed, where it ran and what depended on what. Only then did we lead a rebuild on the MERN stack. That map is the handover document a project should have come with.

If your developer won't hand over the code

Stay calm and stay specific. Most of the time the hold-up is an unpaid invoice or a freelancer who's overloaded.

1. Read the contract first. Know whether you've been assigned the rights and whether every invoice is paid.
2. Ask for named items, in writing. "Please add me as owner on the GitHub repo and transfer the Apple Developer account to our company" gets a better answer than "send me the code."
3. Settle any open invoice. If the assignment only kicks in on final payment, that's usually the fastest way through.
4. Get help if it stalls. A letter from a lawyer usually moves things along. If the code can't be recovered, a new team can rebuild from the live app and your designs. Slower and dearer, but possible.

If you're starting a new build, sidestep all of this. Put the IP assignment in the contract, create the store and cloud accounts in your own company's name on day one, and invite the developer in. When the project ends, you remove them. Nothing has to be transferred because it was always yours.

FAQs

Does paying for an app mean I own the source code?

Not automatically. In the US, code written by a freelancer or agency belongs to them unless your contract assigns it to you in writing. Most professional contracts do assign it, usually once the final invoice is paid. Check yours for an IP or ownership clause.

Can an app developer refuse to give me the source code?

If your contract assigns the code to you and you've paid, refusing is a breach and you can push for it, with a lawyer if needed. If the contract only grants a license, or says nothing, it's harder. That's why the ownership clause and the account setup matter before the build starts.

Should the Apple Developer account be in my name or the developer's?

Yours. Apple ties the app listing, its reviews and its update history to that account. If it sits in the developer's account, you'll need their help to move it later. Create it under your company and add the developer as a team member.

If you're planning an app and want it built so it's yours from the first commit, talk to our mobile app development team. And if you're still choosing who to hire, our guide to mobile app development companies in the USA covers what to ask, and how to scope an MVP helps you decide what to build first.