What a Clean Handoff Looks Like When the Build Ships

A clean handoff means receiving everything you need to operate, update, and maintain the game without depending on the studio that built it. That includes the source code, the build pipeline, the accounts, the documentation, and the knowledge that did not make it into any document. Most handoff problems come from assuming this will happen naturally. It will not.

Why this matters

The moment a build ships is the moment the founder's dependency on the studio changes shape. During production you needed them to build. After launch you need the ability to operate independently, even if you continue working together.

A messy handoff creates a hidden dependency. You own the game on paper but cannot update it, cannot reproduce the build, and cannot onboard a new developer without calling the original team. That dependency has a cost every month it persists.

Getting the handoff right is a one-time effort that prevents a recurring problem.

The deliverables list

Everything below should be in your hands before the final invoice is paid.

Source code. The complete, buildable project in a repository you control. Not a zip file, not a shared account. Your repository, with full history.

Build instructions. A document that lets someone who has never seen the project produce a working build. If it requires tribal knowledge, it is incomplete.

Signing credentials. Store accounts, certificates, provisioning profiles, and anything else needed to submit an update. These must be in accounts you own.

Third party accounts. Analytics, ad networks, attribution, crash reporting, and any other service the game connects to. Transfer ownership or create under your accounts from the start, per the planning approach in Questions to Ask a Game Studio Before Signing.

Asset source files. The editable originals for art, audio, and animation. Receiving only the exported versions means you cannot modify them later.

The test of a clean handoff: can a new developer, with no contact with the original team, produce a working build and submit an update?

The documentation minimum

Three documents cover the practical minimum.

1. Architecture overview. How the project is structured, where things live, and how the major systems connect. One to three pages.
2. Build and deploy guide. Step by step instructions for producing a build and submitting it to each store. Include every tool version and every environment variable.
3. Known issues and workarounds. The things the team knows are fragile, and what to do about them. This document is the most often missing and the most valuable.

Optional but useful: a decision log explaining why major technical choices were made. Future developers will encounter the same questions, and the reasoning prevents them from reversing decisions that had good reasons.

Source code: what to check

Receiving the repository is not enough. Check three things before signing off.

Can you build it? Clone the repo on a clean machine and follow the build instructions. If the build fails, the handoff is incomplete. Do this before the final payment, not after.

Is the history intact? The repository should have the full commit history, not a single squashed commit. History is documentation, and it is the best kind because it was written in real time.

Are dependencies pinned? The build should specify exact versions of every library, plugin, and tool. "Latest" is not a version, and it will break within months.

Accounts and credentials

The category most likely to create an emergency later.

• Store accounts must be yours. If the studio submitted the build through their account, transfer it before the project closes. This is difficult to do later and occasionally impossible.
• Certificates and signing keys must be in your possession. Without them you cannot submit updates, and regenerating them can require removing the app and republishing.
• Analytics and ad network accounts should be under your email from the start. If they are not, transfer them now.
• Domain names and server access if the game has any backend component. Make sure you can log in independently.

A checklist sent at project kickoff prevents most of these problems. The same preparation approach applies to the financial structure described in How Game Development Billing Works.

The knowledge transfer meeting

Documents do not capture everything. Schedule a handoff meeting with these goals.

• Walk through the build process live. Screen-share the build from clone to submission. Record it.
• Review the known issues document together. Ask for the items that did not make it into writing.
• Ask what they would do differently. The answer is useful for the next project and sometimes reveals issues with this one.
• Agree on a support window. Even a clean handoff generates questions. Two weeks of email support after delivery is reasonable and worth paying for.

Record the meeting. The recording becomes the most useful piece of handoff documentation because it captures the implicit knowledge that no document does.

What we would do

Start the handoff checklist at project kickoff, not at delivery. Accounts created under the right ownership from day one do not need to be transferred later.

Build the project from the repository on a separate machine before signing off. This single test reveals most handoff gaps in one step.

Then schedule the knowledge transfer meeting, record it, and store the recording alongside the documentation. The combination of written docs and a walkthrough video covers both the structured knowledge and the implicit kind.

The short version

• A clean handoff means operating the game without depending on the studio that built it.
• Receive source code in your repository with full history and pinned dependencies.
• Get build instructions, architecture overview, and a known issues document at minimum.
• Verify that you can produce a working build on a clean machine before the final payment.
• Transfer or create all accounts and credentials under your ownership.
• Record a knowledge transfer meeting and store it with the documentation.

Start your handoff checklist before the project starts, not at delivery. If you want a development partner that plans the handoff from day one, start a conversation.

Related reading: Questions to Ask a Game Studio Before Signing, Red Flags in a Game Development Proposal, and Client Role During Game Development.