Picture this. Your app is live and people are using it. The agency that built it has stopped answering emails. You decide to bring in someone new, and then you find out you don’t have access to the GitHub repository. The Apple developer account is registered to the agency’s company. The AWS bill goes to their credit card. On paper you paid for the product, but in practice you can’t touch it.
Your software development contract decides whether that’s a bad week or a full restart. Most founders read the price, the timeline and the payment schedule closely, then skim the rest. The rest is where the answer to “who owns the code” is written down. Five clauses do most of the work. Below, each one is in plain English, followed by the wording we use in our own contracts.
We’re engineers, not lawyers. Have your own counsel review anything you sign. What we can tell you is which gaps we see when founders ask us to take over or audit a codebase.
Why the software development contract matters more than the code
Code you can’t legally use, can’t access, or can’t deploy isn’t worth much, however good it is. Outsourcing software development to a studio, a freelancer or an offshore team carries the same risk: if the relationship ends badly, what you walk away with depends on what was agreed in writing before any work started.
There’s also a legal default most founders don’t expect. In many jurisdictions, including India and the US, work done by an outside contractor does not automatically belong to the client. Copyright usually transfers only through a written assignment. Without one, you may have paid for a licence to use the code rather than ownership of it.
The five clauses, and the wording we use
1. IP assignment
This clause transfers ownership of the code, designs and documentation from the developer to you. Check two things. First, it should say “assign,” not “license.” Second, look at what it leaves out. Many shops keep ownership of their “pre-existing tools” or “frameworks,” which is fair, but if that category is vague it can end up covering half your backend.
Our wording:
“On payment of each invoice, all right, title and interest in the Deliverables covered by that invoice, including source code, designs and documentation, is assigned to the Client. Any pre-existing Developer materials included in the Deliverables are licensed to the Client on a perpetual, royalty-free, non-exclusive basis, and are listed in the repository README.”
We tie ownership to payment, and we’re open about that. It protects us, and it also means ownership moves to you in stages, invoice by invoice, instead of all at once when the project ends.
2. Repository ownership
Ownership on paper doesn’t help if the only copy of the code sits in the vendor’s GitHub organisation. The repository should be created under your account from the first day, with the developers added as collaborators.
“All source code will be kept in a version control repository owned by the Client’s organisation account. The Developer will work in that repository as a collaborator and will not keep the primary copy elsewhere.”
This also gives you visibility as the project runs. You can see commits land week by week, which says more about progress than a status deck does.
3. Credentials and access
Production databases, CI/CD pipelines, admin dashboards and server keys should all have you as the owner, with developers given their own access that you can revoke. Watch out for shared logins. When five people use the same password, you can’t remove one of them without breaking things for the other four.
“The Client is the owner of every production system. Each Developer team member receives individual, revocable access. A current list of systems and who has access is kept in the repository and updated whenever access changes.”
4. Third-party accounts
Founders miss this one most often, and it’s the most painful to fix later. A modern product depends on a stack of outside accounts: cloud hosting, the Apple App Store and Google Play developer accounts, the domain registrar, Firebase, payment processors, and for AI features, the LLM provider’s API keys. Moving an app between App Store accounts is possible, but it’s slow, and some things don’t come across cleanly. It’s much easier to register everything in your name from the start.
“Accounts for third-party services needed for the Deliverables, including cloud hosting, app store developer accounts, domain registration, payment processing and AI model providers, will be registered in the Client’s name and billed to the Client directly.”
You get one extra benefit: you see real infrastructure costs every month, not a marked-up line on an invoice.
5. Exit assistance
Nobody likes to plan the breakup at the start of the relationship, but that’s the only time both sides are still being reasonable. This clause says what the vendor has to hand over when the engagement ends, for whatever reason.
“On termination for any reason, the Developer will deliver within ten business days: the current source code, build and deployment instructions, environment configuration (without secrets, which remain in Client-owned systems), and a written list of known issues and unfinished work. The Developer will also join a handover session with the Client’s new team at standard rates.”
“Known issues and unfinished work” matters more than it sounds. Whoever takes over will need to know where the technical debt is. Without that list, they’ll spend their first few weeks finding it themselves, at your expense.
How to check your current contract in 15 minutes
If you already have a vendor, you don’t need to renegotiate everything. Go through these questions:
- Does the contract say the IP is assigned to you, and when does that happen?
- Could you log into the code repository today without asking anyone?
- Are the App Store, Play Console, cloud and domain accounts in your company’s name?
- If your lead developer left tomorrow, is there written documentation of how to deploy?
- Does anything describe what happens when the engagement ends?
Answering “no” to any of these isn’t a disaster. Most vendors will move accounts or add a short amendment if you ask while things are going well. It’s far harder to ask once things have gone wrong.
At orithLabs, these five clauses are standard in how we work, and we’d rather you hold us to them than take our word for it. If you’re dealing with a stalled build or a codebase you inherited and aren’t sure what you actually own, a code audit is a sensible first step. We’ll tell you what’s there, what’s missing, and what it would take to get it under your control, including when the honest answer is that it’s in better shape than you feared.