Who owns your game when you outsource development?

Founders usually assume that paying for work means owning it. In most jurisdictions that is not how copyright operates by default. Unless a contract explicitly assigns rights to you, the party that created the work may well retain them. You may end up with a licence to use your own game rather than ownership of it.

This almost never causes a problem while everyone is getting along. It causes a problem at exactly the worst moment: when you want to change studios, when you are raising money and an investor runs diligence, or when you want to sell.

1. Get an explicit assignment of IP

The contract needs a clause that assigns all intellectual property in the deliverables to you, not one that grants you a licence. Words to look for and to be wary of:

• "Assigns" is what you want. "Grants a licence to" is not the same thing and is much weaker.
• "All deliverables" should be defined to include source code, art source files, project files, documentation and build configuration, not just the compiled game.
• Moral rights should be waived where the law allows it, so a former contributor cannot object to how the work is later changed.
• The assignment should cover work in progress, not only finished deliverables, so a project abandoned mid-way still leaves you holding what was built.

2. Decide when ownership transfers

Most studios, us included, tie transfer to final payment. That is reasonable and protects both sides. What matters is that it is written down and that you know what happens if the project stops early.

Ask directly: if we cancel after milestone two, what do I own? A fair answer is that you own everything paid for up to that point. If the answer is that you own nothing until the final invoice clears, you are carrying the entire risk of a project that may be cancelled for reasons on either side.

3. Third party assets are where this usually goes wrong

This is the most common real-world failure, and it rarely involves bad intent. Modern game development assembles a lot of other people's work: Unity Asset Store packages, plugins, fonts, sound effects, music, stock art, open source libraries.

A developer cannot assign to you rights they never had. So the contract should require a third party asset register: a list of every external asset used, where it came from, and under what licence. Ask for it as a deliverable, updated at each milestone.

Specific traps worth knowing about:

• Unity Asset Store licences are usually per-seat and non-transferable. If your studio bought an asset under their account, you may need to buy your own copy. Better to know this at milestone one than at launch.
• Fonts are software and are licensed, frequently with separate terms for apps and games. Desktop licences often do not cover embedding in a game.
• Music and sound effects frequently carry royalty-free licences that still restrict resale or require attribution.
• Copyleft open source in a shipped game can create obligations you did not intend. Ask what licences are in the dependency tree.
• AI-generated assets have an unsettled ownership position in many jurisdictions. If any were used, you want to know, and your investors will ask.

4. Ask for the repository, not a zip file

"You get the source code" can mean a zip file of the final state, which is technically true and practically much less useful. What you actually want:

• Access to the version control repository with its full history, ideally under your own organisation account from day one
• Build instructions that a different developer can follow, with engine version and plugin versions pinned
• Art source files, not just exported assets. The .blend and the layered .psd, not only the .fbx and the .png
• Credentials and accounts held in your name: store accounts, analytics, ad networks, backend services

That last point matters more than people expect. A game whose store listing and backend sit inside someone else's account is not fully yours whatever the IP clause says.

5. Escrow, if the game is business-critical

For larger engagements, source code escrow puts a current copy of the code with a neutral third party, released to you if defined conditions occur, such as the studio becoming insolvent.

It costs money and adds admin, so it is overkill for a small project. It is worth considering when the game is the business, or when a funder asks for it. A lighter alternative that covers most of the risk: require that all code is pushed to a repository you own, continuously, from the first day.

6. Portfolio rights, in both directions

Most studios want to show the work. Most clients are fine with that after launch and not before. Write down which it is.

A workable clause: the developer may reference the project publicly after public release, and the client may revoke that permission in writing at any time. If you are in stealth, say so up front; a studio that cannot agree to that is telling you something useful.

7. The clauses founders regret leaving out

• A defined warranty period. How long after delivery will defects in the delivered work be fixed at no cost, and what counts as a defect rather than a new feature.
• A change process. Scope will change. Agree how changes are priced and approved before it happens, not during the argument.
• Key person continuity. If you are hiring partly because of one specific lead developer, say so in the contract.
• Data protection. If the game collects player data, who is the controller and who is the processor, and which regimes apply.
• Governing law and dispute resolution. Cross-border contracts need a named jurisdiction. Pick one both sides can realistically use.
• An exit plan. A handover period, paid at an agreed rate, so a transition does not depend on goodwill.

Questions to ask on the first call

You can learn most of what you need before any paperwork exists. Ask these, and pay attention to whether the answers are specific:

1. Who owns the IP and source code, and at what point does it transfer?
2. Will you work in a repository under my organisation from day one?
3. Can you provide a register of every third party asset and its licence?
4. What exactly is in the handover package at the end?
5. What happens to my deliverables if I cancel after the second milestone?
6. Will you sign my NDA, or do you require your own?

A studio that answers these clearly and without hedging is showing you how the rest of the engagement will go. One that gets uncomfortable is also telling you something.

For the record, our answers are: you own it, transferring on final payment; yes, your repository from day one; yes, maintained per milestone; the full project, source files and credentials; you own everything you have paid for; and we sign yours.