Start with relevant experience

Look for comparable loops, interfaces and project stages. Ask whether images are captured gameplay, interface views or promotional artwork. Our team completed full development of the four Unity games in our portfolio, and the case studies identify the media shown. Use the board-game example to discuss controls and match flow, then agree the networking requirements and player capacity for your own game.

Ask about the team’s actual role

Was the team responsible for full development, one system or maintenance? Who supplied artwork, audio and third-party assets? Ask about the relevant game-development experience of the people who would work on your project, their responsibilities and how the team would be organised for your scope.

Assess inherited work before committing

For an existing project, describe what works, what remains and who controls the source. Agree a safe working copy and the scope of assessment. Clarify dependencies, build access and available documentation through a secure process. Avoid sharing passwords in a public enquiry.

Define milestones and acceptance

Describe observable behaviour for each deliverable, review points and who signs off. Agree the supported devices and how bugs are distinguished from new requirements. A playable milestone is more useful than a vague promise that a game is nearly finished.

Clarify source and asset handover

Discuss source access, build instructions, asset files, licences and documentation. State which third-party accounts belong to the client and which dependencies require ongoing payment. Ownership, transfer and access terms must appear in the agreement rather than being inferred from a portfolio.

Agree testing and publication responsibilities

Ask who supplies devices, test data, account access and store materials. Define gameplay, interface, progression and compatibility checks relevant to the scope. Make release approval responsibilities explicit. No team can promise that testing guarantees approval or commercial success.

Make communication and changes manageable

Agree the review cadence, decision maker and feedback format. Discuss time-zone practicalities. When a new feature is proposed, record its effect on cost, delivery and acceptance before adding it. Clarify how revisions are scoped and how questions and feedback will be handled.

Plan support and dependencies

Ask how post-launch bugs, content updates and platform or service changes will be handled. Confirm the support period, exclusions and escalation route in the scope. For online games, separate application development from operating services. For content-rich games, agree how future items and scenes can be added.

Bring a brief to the first discussion

  • Your idea, platform and first-release priorities.
  • Relevant portfolio examples and why they fit.
  • Existing code or asset condition and ownership.
  • Questions about milestones, acceptance, handover and support.