The short version: A playable build is not a complete handover; define scope, acceptance, source files, rights, dependencies, and change control before work begins.

The most expensive studio dispute is often a missing definition. โ€œBuild the gameโ€ does not say which platforms, features, assets, source files, revisions, or acceptance tests are included. A serious statement of work turns the promise into inspectable deliverables.

Define the handover

List the repository or project files, build targets, art and audio sources, third-party licences, credentials to transfer, documentation, and known limitations. Specify the build number and the test environment. If the client receives only an executable, say so explicitly.

Separate ownership from access

A client may receive a licence, an assignment, or a work-made-for-hire result depending on the contract and jurisdiction. The U.S. Copyright Office explains that work made for hire has specific statutory conditions; a label in an invoice is not a substitute for an appropriate written agreement.

Use acceptance tests

Attach a short checklist: installation, launch, input, save/load, core loop, performance target, known bugs, and required documentation. Give the client a response window and describe what counts as a change request rather than a defect.

This is educational information, not legal advice. Have counsel review the agreement for the governing jurisdictions and the actual rights being transferred.

Primary source

game studiocontractswork for hireoutsourcingproduction