How to Avoid Lock-In With Your Game Studio

You avoid lock-in by owning the things a game is made of from day one: the code repository, the store accounts, the third-party licences and the build instructions. If those sit in your company's name, you can switch game development studio and keep your source code at any milestone. The contract confirms it; the setup makes it real.

Why lock-in is a runway problem

Lock-in rarely comes from bad intent. It comes from convenience. The studio creates the repo, opens the ad accounts and buys the plugins because that is faster in week one.

Twelve months later you want a second opinion, a cheaper team for live ops, or an in-house hire. Then you find the project lives in someone else's accounts, and getting it out costs weeks you did not budget for.

For a funded founder, those weeks come straight out of runway. Your board will not care whose fault it was. They will care that the roadmap slipped.

The five things you need to own

Think of your game as five assets. A studio can build all of them, but none of them should live only with the studio.

If a studio pushes back on any row, ask why. There is usually a fine reason, such as a shared internal tool, and usually a fair fix.

The signing key matters more than people think

On Android, updates to a live app must be signed with the same key, or managed through Google Play App Signing. If the only copy of the upload key sits on one engineer's laptop, no contract clause fixes that quickly. Get the keystore and its passwords into your own vault before the first store build.

What the contract should say

Ownership in practice comes first, but the paperwork still matters. For a fuller walk through of the rights involved, read who owns your game, its IP, source code and assets.

Look for these clauses, in plain words.

1. IP assignment on payment. Work product becomes yours as each milestone is paid, not only at the end.
2. Source delivery at every milestone. Full project, not just a build. Include art source files, not only exported sprites.
3. Transition help on exit. A set number of hours at an agreed rate to brief whoever comes next.
4. Pre-existing tools. If the studio reuses its own framework, you get a permanent licence to use it inside your game.
5. Third-party list. Every SDK, plugin and asset pack, with its licence, delivered with the source.

Ask a lawyer to read the final version. This is a checklist for the conversation, not legal advice.

The documentation that makes a handoff possible

Owning the repo is half of it. A new team also needs to open the project and ship a build without calling the old one.

Ask for a short living document in the repo root that covers:

• Unity version and every package version, pinned
• How to produce a release build for each platform, step by step
• Where every secret lives and who can rotate it
• Which scenes, prefabs and systems are fragile and why
• How remote config, analytics events and ad placements are named

A good test is simple. Hand the repo and the document to a developer outside the project. If they can make a signed build in a day, you are not locked in.

Ownership on paper is a promise. A build that someone else can produce from your repo is proof.

How to check you are not locked in already

If the project is underway, run this audit this week. It takes an afternoon.

1. Log in to the repo as your company admin. Confirm you can see every branch and the full history.
2. Open App Store Connect and Play Console. Confirm your company holds the top role.
3. List every service the game talks to. Confirm you can log in to each one yourself.
4. Ask for the Android keystore and iOS certificate details. Confirm they are in your vault.
5. Ask an outside developer to clone and build. Note every question they had to ask.

Each gap you find is cheap to fix now and expensive to fix during a dispute. Our post on technical due diligence on a build you did not write goes deeper on step five.

What switching studios actually costs

Even with perfect ownership, a switch is not free. A new team needs time to read the code, learn the quirks and earn the confidence to change things.

As a rough planning example, budget two to four weeks of slower progress after a handover on a mid-sized mobile project. That figure is illustrative, so ask any incoming team for their own estimate after they have read the code.

The point of avoiding lock-in is not to make leaving painless. It is to make leaving possible, so you choose your partner on merit every milestone.

What we would do

We would set up the repo, store accounts and service logins under the founder's company before writing a line of code, and invite ourselves in. It takes an hour and removes the biggest risk on the project.

We would deliver full source at every milestone, keep the build document current, and treat a clean handoff as part of the job. A studio that is confident in its work has no reason to hold your project hostage.

The short version

• Lock-in comes from convenience in week one, so fix the setup before the build starts.
• Own the repo, store accounts, services, paid assets and signing keys in your company's name.
• Get IP assignment on payment, source at every milestone and transition hours in the contract.
• Keep a build document good enough for an outside developer to ship from.
• Audit your current project this week if it is already running.

If you want a studio that sets the project up in your name from day one, talk to us.

Related reading: What a Clean Handoff Looks Like When the Build Ships, Ten Questions to Ask a Game Studio Before You Sign