Who Owns Your App's Code? What to Get in Writing

Most founders assume that if they pay for an app, they own the app. In many places the default legal rule says otherwise. Absent a written agreement, the person who writes the code often owns the copyright, and the person who paid gets, at best, an implied permission to use it. That gap has sunk fundraising rounds, acquisitions and more than one relationship with a developer who suddenly wanted more money.

This is a practical checklist, not legal advice. Copyright and contract rules vary by country and by state, and the right wording depends on your situation. Have a lawyer who handles software or IP contracts review whatever you sign. An hour of their time costs a few hundred dollars. Untangling a disputed codebase costs tens of thousands.

What follows is what we would ask for if we were on your side of the table. If you are still comparing options, our guide to in-house vs agency vs freelance covers who to hire. This piece covers what to put on paper once you pick.

There are two ways an agency can hand you rights to the code. They sound similar and they are very different.

• Assignment. The agency transfers its ownership to you. After that, you are the owner of the copyright in the deliverables. You can sell the company, hire someone else, or rewrite the thing in another language without asking permission.
• License. The agency keeps ownership and gives you permission to use the code. The license might be exclusive or not, perpetual or time limited, transferable or not. Every one of those words matters.

Some agencies use licenses deliberately. They reuse components across clients and want to keep the right to do so, which is reasonable for generic pieces such as a login screen or an admin table. A license for the whole product is another matter. If your contract says "Client is granted a non-exclusive license to use the Work Product," you do not own your app. The agency could, in theory, sell the same codebase to your competitor.

Our position: the custom code written for you should be assigned to you. Pre-existing agency tools and shared libraries can be licensed to you on a perpetual, irrevocable, royalty-free basis, with the license surviving termination and passing to a buyer if you sell the company. Look for the words "assign" and "all right, title and interest." If you only see "license," ask why.

Also check whether the assignment covers more than code. Designs, wireframes, copy, database schemas, API documentation, app icons and test suites are all part of what you paid for. A clause that says "source code" and nothing else leaves the rest ambiguous.

Founders hear "work for hire" and assume it settles ownership. In the United States, the doctrine is narrower than it sounds. For an independent contractor, a work only counts as made for hire if it falls into specific statutory categories and the parties agreed in writing. Custom software does not fit neatly into those categories, and lawyers disagree about how often it qualifies. Other countries treat the idea differently or not at all.

The fix is boring and standard: pair the work-for-hire language with a backup assignment. The contract says the work is made for hire to the extent the law allows, and to the extent it is not, the agency assigns all rights to you. Belt and suspenders. If a contract has the first half without the second, ask for the second.

The same thing applies to the people at the agency. The company needs written assignment agreements with its own employees and contractors, otherwise it cannot hand you rights it never held. Ask for a clause where the agency represents that every person who touches your code has signed an agreement assigning their work to the agency. Ask which of their developers are overseas contractors, and whether those contracts carry the same terms. A chain of title is only as strong as its weakest link.

Moral rights are a smaller point that matters in some countries. In parts of Europe, authors keep certain rights that cannot be signed away, so agreements there usually include a waiver or a promise not to assert them. Your lawyer will know whether it applies.

Many agency contracts say ownership transfers "upon full payment." That is common and mostly fair. The agency does not want to hand over its work and then chase an invoice. But the details can hurt you.

Watch for these:

• Full payment of what? The whole project, or each milestone? If ownership only transfers when the final invoice clears, the half-built app you paid $60k for belongs to the agency until the end. If the relationship sours in month three, you own nothing.
• Disputed invoices. If you withhold payment over a defect, does the clause let the agency claim you never "fully paid" and therefore never owned anything? A good contract transfers rights milestone by milestone, and says a good-faith dispute does not block the transfer of paid-for work.
• Interim use. Between signing and the final payment, you need a license to run the code you have already received. Otherwise you are technically infringing while you test your own beta.
• Termination. If either side ends the contract early, what happens to the code written so far? The clean answer: you pay for work done, you get an assignment of work done, and the agency hands over the repo.

Our preference is assignment on payment of each milestone invoice, with an interim license for everything delivered. It is fair to the agency, since unpaid work stays theirs, and fair to you, since paid work is yours. Our breakdown of software development contract types and pricing shows how milestone structures work, and it is worth reading before you negotiate this clause, because the payment schedule and the ownership schedule should line up.

No modern app is written entirely from scratch. A typical React Native or Next.js project pulls in hundreds of open source packages. An agency cannot assign you ownership of code it does not own, so the contract should handle this layer separately.

Ask for these three things:

1. A dependency list. A software bill of materials, or at minimum the package manifest and lockfile, plus a list of any commercial SDKs, paid fonts, stock assets and APIs. Tools such as npm's license checkers or FOSSA can generate a license report in minutes.
2. A promise about license types. Permissive licenses (MIT, Apache 2.0, BSD) are generally safe for commercial apps. Copyleft licenses (GPL, AGPL) can require you to publish your own source under certain conditions, and the AGPL reaches network use, which matters for a hosted backend. The contract should say the agency will not include copyleft code in your product without your written approval.
3. A warranty of non-infringement. The agency states that, to its knowledge, the work does not infringe anyone's rights, and that it did not copy code from a previous client or an employer. Expect them to limit this, and expect a limit on liability. A total absence of any warranty is a flag.

Be wary of agency "accelerators" and starter kits. Reusing a boilerplate is smart. The question is whether that boilerplate is licensed to you in a way that lasts. If the agency's internal framework is proprietary and the contract only gives you a license that ends when the engagement ends, you might be unable to run your own app without them. Ask whether the proprietary pieces are included, replaceable, or licensed perpetually. The same scrutiny belongs on any item you see during a proposal review, and our list of software development proposal red flags includes several versions of this one.

Here is the part that gets founders in the most trouble in practice. You can have a perfect assignment clause and still be locked out, because the assets that run your product sit in accounts the agency controls. Ownership on paper and control in practice are different things.

The rule is simple: every account should be created under your name, your company and your email address from day one, with the agency added as a collaborator. Not the other way around. Transferring an account later is possible but slow, and some transfers are painful or impossible.

• GitHub (or GitLab, Bitbucket). Create a GitHub organization owned by your company. Make two people on your side owners. Invite the agency's developers as members or outside collaborators. Do not accept a repo living in the agency's organization with an "export" promised at the end. Commit history is part of the asset, and you want it intact.
• Apple Developer Program. Enroll as an organization, which costs $99 a year and requires a D-U-N-S number, so start that early because verification can take days or weeks. Add the agency through App Store Connect roles. If the app is published under the agency's developer account, moving it to yours means an app transfer with its own requirements, and you can lose some history.
• Google Play Console. A one-time $25 fee. Organization accounts now go through identity verification as well. Same rule: your account, their access. App transfers exist but add friction.
• AWS, Google Cloud, Azure or Vercel. Your billing account, your root credentials stored in your password manager with multi-factor on a device you control. The agency gets IAM users with the access they need. A production database in an agency account is a hostage situation waiting to happen.
• Domains and DNS. Register the domain yourself at a registrar such as Cloudflare or Namecheap. Agencies who register domains "as a courtesy" end up as the registrant of record. Check the WHOIS entry.
• Everything else. Firebase, Stripe, Sentry, Twilio, SendGrid, Apple push certificates, signing keys, analytics, app store listings, the Figma files. Keep a spreadsheet listing each service, the account owner, and who holds admin rights.

Put the account rule in the contract as well. A sentence like "All accounts, credentials, keys and repositories used in the project shall be registered in Client's name" costs nothing and turns a favor into an obligation.

Most agencies now use AI coding tools such as GitHub Copilot, Cursor and Claude Code, and so should the good ones. The speed gain is real. The legal footing is less settled, and your contract should say something about it.

Two issues sit underneath. The first is authorship. In the United States, the Copyright Office has said that copyright protects human authorship, and that purely machine-generated material is not protected, while human-directed and human-edited work can be. Code written by a developer who prompts, reviews, rewrites and integrates AI output sits in a gray zone that depends on how much human creative control went into it. Other countries have their own rules, and courts are still working through cases. Nobody can promise you a clean answer today.

The second is provenance. A model trained on public code can occasionally produce output that resembles existing licensed code, including copyleft code. Vendors offer different protections. Some enterprise plans include indemnification for output, others do not, and the terms differ by vendor and plan.

What to ask for:

• A disclosure of which AI tools the agency uses on your project, and which plan tier, so you can read the vendor terms.
• A statement that developers review and take responsibility for all AI-assisted code, rather than pasting output unseen.
• Duplicate-code filters turned on where the tool offers them, such as Copilot's public code matching setting.
• A confidentiality rule: no pasting your proprietary data, customer records or secrets into tools that train on inputs.
• An assignment that covers AI-assisted output to the fullest extent the law recognizes, with the agency agreeing to provide reasonable help if ownership is ever challenged.

Be careful about agencies that promise "you will own 100% of everything" with no mention of AI at all. They either do not use it or have not thought about it. Neither is comforting. If the exact status of AI-assisted code matters to your valuation, for example in a venture round, tell your lawyer now, because investors' counsel increasingly ask the question in diligence.

Owning a repo you cannot run is not much better than not owning it. Write a handover package into the contract as a deliverable, tied to final payment, so it is not an afterthought. Ask for:

• A README that actually works. A developer who has never seen the project should be able to clone it, install dependencies, and run it locally in under an hour by following the file.
• An architecture overview. One or two pages: what the services are, how data flows, which third parties are involved, and why the main technical decisions were made.
• Environment and secrets documentation. Every environment variable, what it does and where it lives. Not the secrets in a document, but a list of what exists and a secure transfer of the values.
• Deployment instructions. How a release gets built, signed and shipped to TestFlight, the App Store, Google Play and your servers. If you cannot ship a bug fix without the agency, you depend on them.
• Infrastructure as code. Terraform, CDK or the equivalent, so your cloud setup can be rebuilt rather than recalled from someone's memory.
• Database schema and migration history, plus a tested backup and restore procedure.
• Design files. The Figma file with edit rights, fonts, and exported assets.
• A walkthrough session. A recorded call, usually one to two hours, where the lead developer shows a new engineer around the codebase.

Ask for a dry run before the final milestone. Have an independent developer, or one of your own hires, follow the handover docs on a clean machine. Whatever breaks in that exercise is what you would have discovered on the worst day of your year. Budget a few days of a senior freelancer's time for this, often $1,000 to $3,000 depending on the codebase. It is some of the best money you will spend on the project.

Your bargaining power is highest before you pay anything, so this is the moment to ask. Use this as a pre-signature checklist:

1. The contract contains an assignment of all custom deliverables, not just a license, and covers code, designs, documentation and data.
2. Work-for-hire language is backed up by a present assignment ("hereby assigns").
3. Ownership transfers milestone by milestone as you pay, with an interim license for anything delivered but not yet fully paid.
4. The agency has signed assignment agreements with every employee and subcontractor on your project, and says so in the contract.
5. Pre-existing agency code is licensed to you perpetually, irrevocably and transferably, and the contract names which components those are.
6. Open source use is permitted only under licenses you approve, and the agency delivers a dependency and license report.
7. You have disclosed and agreed the policy on AI coding tools.
8. Your GitHub organization, cloud accounts, Apple and Google developer accounts, domains and third-party services are created in your company's name first, with you holding owner rights.
9. A handover package is a listed deliverable, with a date, and final payment depends on its acceptance.
10. The agency may not use your code, data or name in a portfolio, case study or a future product without your written consent. Portfolio rights are a normal ask from agencies, and you can grant them, but grant them on purpose.
11. Confidentiality and non-compete terms are reasonable. The agency can build other apps, but it should not rebuild yours for your competitor with your code.
12. A lawyer has read it.

If an agency pushes back on all of this, treat that as information. A good one might negotiate details such as the milestone mechanics or portfolio rights, and will usually say yes to account ownership and a handover package without a fight. We cover more patterns of this kind in our article on proposal red flags. Evasive answers about who controls the repo are at the top of the list.

Once the paperwork is in order, you can focus on the part that makes the app worth owning. If you want a second pair of eyes on a contract you have been handed, or a plan for building the product with ownership clean from the first commit, Book a free strategy call.