Who Actually Owns Your Code? A Non-Technical Founder's Guide to IP, Repos, and Contracts 🔐
Here is a conversation we have had more than once. A founder calls us, unhappy with their current development shop and ready to move on. We ask one simple question: do you have access to the code? Long pause. It turns out the repository lives in the agency's account, the domain is registered under a developer's personal email, and the contract signed two years ago says nothing about who owns what. The work is paid for. The ownership is a mess.
These situations are almost never malicious. They happen because nobody brought it up at the start, when sorting it out would have taken ten minutes. This is the checklist we wish every founder had before signing.
Paying for It Doesn't Automatically Mean Owning It
This surprises people, so it is worth stating plainly: in the United States, when you hire an outside contractor or agency, the default rule is that whoever writes the code owns the copyright to it unless there is a written agreement transferring it to you. "Work made for hire" is a specific legal category that mostly applies to employees, not contractors, so putting that phrase in an email does not settle anything. What settles it is a written assignment of intellectual property. Without one, you may have paid for an app you only have an implied license to use, which becomes a very real problem the day you want to raise money, sell the company, or hand the code to a different team. We are not attorneys and this is not legal advice, but we want to pass on common knoweldge to help you avoid common pitfalls we see.
The Five Things That Should Have Your Name on Them
Ownership is not one item, it is a set of accounts. For each of these you want to be the owner of record, with your developer added as a collaborator or admin. That distinction matters: access can be granted and revoked, ownership cannot easily be taken back.
The domain name. Registered to your company with your email on the account. Check this one first, because it is the most commonly misfiled asset of all.
The code repository. GitHub, GitLab, or Bitbucket. The organization should be yours, with your developer invited into it, not the other way around.
Hosting and cloud accounts. AWS, Digital Ocean, Vercel, Google Cloud, or whatever actually runs your app, billed to your card and under your login.
App store developer accounts. Your Apple and Google accounts should be registered to your business entity. Moving an app between developer accounts later is possible, but it is tedious, and it interrupts your users.
Design files and brand assets. Figma files, logo source files, and any photography licenses. These get forgotten until the day you need to redesign something and discover you only have a flattened PNG.
Contract Language Worth Reading Twice
You should be able to find five things and confirm they are in any standard Development Agreement for building a mobile app. An intellectual property assignment that transfers ownership of the work to you, ideally upon payment. A definition of deliverables that names the source code specifically, not just the finished application, because those are not the same thing. Terms describing what happens if payment is late, since many contracts hold transfer until the final invoice clears, which is fair but worth knowing. A confidentiality clause covering your idea, your data, and your customers. And finally, termination and handoff terms that spell out what you receive if the relationship ends: a copy of the repository, documentation, credentials, and a reasonable transition period. If the contract is silent on that last point, ask for it before you sign. It costs nothing at that stage and it is awkward to negotiate later. Our guide to red flags to watch for when hiring a development agency covers the other warning signs worth catching before you commit.
Third-Party Code, Licenses, and the AI Question
Almost no modern app is written entirely from scratch. Yours likely includes dozens of open-source libraries, and the great majority carry permissive licenses that cause you no trouble whatsoever. A few come with conditions attached, and certain copyleft licenses can require you to publish your own source code if you distribute software built on them. A good developer tracks this and keeps you clear of it, so it is fair to ask whether anyone has run a license check. Then there are the paid pieces: a mapping API, a payment integration, a premium plugin, a font license. Ask which of those are billed to the agency's account rather than yours, because those subscriptions tend to vanish when the relationship does. Ideally, 100% of these accounts should be under your name, brand, and billing details to ensure a smooth transition if you ever plan to switch development teams later on or hire in-house.
AI-assisted code adds a newer wrinkle. Using AI tools in development is now completely normal and generally fine, but ownership of purely machine-generated output is still an unsettled area of copyright law, and investors doing diligence have started asking how code was produced. You are entitled to a straight answer: which parts were AI-assisted, and what human review did they get before shipping?
Your 30-Minute Ownership Audit
If you already have an app or website live, you can check most of this yourself this afternoon. No technical skill required.
Start with the domain. Run it through a public WHOIS lookup and see whose name and email are attached to it.
Open the code repository. If you cannot log in, or you do not know where the code lives, you already have your answer. Simply being on the account is not enough. You must be the owner and an adequate development team can "transfer" the repository to you as long as you ask.
Check every account. Log in to each hosting, cloud, and app store account and confirm you are listed as the owner, not merely a user with access. Be cautious which developers are still on those accounts as high permissioned users. Its very common years later old team members are still on your project which can become a large security issue.
Search your contract. Look for the words ownership, intellectual property, and assignment. If none of them appear, that is worth a call to an attorney.
Ask for a written inventory. Email your developer and request a list of every account, license, and subscription tied to your product, including who the account holder is for each one.
What If You Don't Like the Answers?
Do not panic, and do not open with accusations. In our experience, the overwhelming majority of these situations are simple oversight, and most developers will transfer everything over without argument once they are asked directly and in writing. Start there: a friendly, specific request to move the domain, transfer the repository to you, and sign a short IP assignment covering the work already delivered. If you get resistance or silence instead, that tells you something important, and it is worth a conversation with an attorney before you put another dollar into that codebase. Either way, finding out now is far better than finding out during a funding round, when a clean chain of ownership is often the difference between a deal closing and a deal stalling. If you are weighing your options for who builds what comes next, our 10 questions to ask before hiring an app developer is a good place to start.
Own What You Paid For
Every project we take on at Founders Approach we do our best to set you up for success from the start. This means our Project Managers walk you through the (sometimes confusing) process of signing up for all of these accounts. That way you own them from Day 1 and you simply add us back to them as high permissioned users so we can do what we need to bring your mobile app to life.
If you are not sure where you stand with your current develompent team, we are happy to walk through it with you and tell you honestly what we see. Reach out through our Contact Us page and let's take a look together.
