Nine questions before you buy a game studio

I have been on the sell side of two studio acquisitions. It is a peculiar education. For several months you decide what belongs in a data room, answer questions at speed and become very aware of the gap between the documents a buyer requests and the things they would need to understand the business.

General technology diligence still matters. Security, employment, finance and corporate structure do not become optional because there is a dragon in the product. But games have their own failure modes, and a standard software checklist can walk past them quite happily.

These are the nine questions I would want answered before signing.

1. Does the studio own everything it believes it owns?

Start with the asset list, then match it to contracts. Code, art, music, writing, mocap, trailers, fonts and marketing work may have been created by employees, founders, freelancers, outsource studios or a helpful friend during a difficult milestone. The ownership position is only as strong as the paperwork for each of them.

I would pay particular attention to work created before the company existed, by people who were never employees, and under agreements copied from a previous project. “All contractors signed our standard terms” is useful only after somebody has checked which version and whether the signed documents can be found.

A representation in the purchase agreement is not the same as discovering the problem while it can still be fixed.

2. What happens if two named people leave?

Not “Does the company have key-person risk?” Almost every small studio does. Ask for the names.

Who alone understands the build pipeline, engine fork, backend deployment, publisher relationship or combat system? Is the knowledge written down? Can another person produce a release? What would make those people stay after a transaction, and have they been asked?

An organisation chart tends to understate this. The person with the relevant title may not be the person everyone messages when the console build fails at midnight. Interviews and repository history often reveal the real dependency much faster.

3. Does the milestone plan describe the game in the build?

I want the last three milestone plans, what actually shipped in each, and the current build on target hardware. The comparison is more informative than the newest schedule by itself.

Separate remaining content from remaining invention. Producing twenty more items through a stable pipeline is not the same as finishing an unproved multiplayer architecture. Ask what “done” means, where integration and certification sit, and how much slack exists. If every remaining task is on the critical path, the plan has expressed hope very precisely.

Then play the build. A schedule can say “feature complete” while the game still has prototype loading, placeholder flows and systems which only work when operated by their author.

4. What third-party code is in the product?

Request a software bill of materials covering the engine, middleware, plugins, SDKs and open-source components. It should include versions, licences, modifications and who owns each dependency inside the team.

The awkward dependency is often not the expensive middleware with a visible contract. It is the old plugin which quietly entered the project, was modified locally and is now essential to loading a save. Can it be updated? Can it be removed? Is its licence compatible with distribution? Does the company know where it came from?

The quality and speed of the answer is itself useful. A maintained inventory suggests dependency changes are controlled. A week of searching suggests otherwise.

5. What does the engine agreement say about this transaction?

Do not assume the public engine terms are the studio’s terms. There may be a custom licence, royalty treatment, minimum commitments, support arrangements or negotiated exceptions.

Check change-of-control and assignment provisions, payment history, reporting obligations and any modifications which affect upgrade or support. The question is not merely whether the current game can ship. It is what rights and costs the buyer inherits, and whether the transaction itself requires consent.

6. Can the platform and publishing agreements move with the company?

Publisher, platform, distribution and co-development agreements can contain approval, assignment, termination and change-of-control language. They may also define sequel rights, recoupment, delivery obligations, marketing commitments and ownership in ways the headline commercial summary does not.

I would also look at certification history. Repeated failures can expose process and ownership problems which are not visible in the current risk register. Who handles submissions? How early are platform requirements tested? Are there waivers or unresolved issues attached to the product?

7. Where has generative AI been used, and what record exists?

“We do not ship AI-generated art” is no longer a complete answer. Use may include code completion, concept work, localisation, audio, marketing, support tools and material supplied by vendors.

Ask for the policy, approved tools, account terms, records of material use and the review process. Separate experimentation from content shipped in the product. Check publisher and platform warranties against what the team and its suppliers actually did.

The risk is not only a dramatic ownership dispute. It is also being unable to answer a partner’s ordinary provenance question during approval because nobody kept a record.

8. What does it cost to operate the game?

For a connected or live product, I want infrastructure cost per active user, not only the current monthly bill. How does it scale? Which services are contracted? What happens to the unit economics at a smaller or larger audience?

Then add the people. Live operations, customer support, security, analytics, moderation, incident response and content deployment do not happen by themselves. Check player-data flows, access control and the team’s ability to restore service, not merely the existence of a backup.

A game can be technically operable and commercially unpleasant. The diligence needs both answers.

9. What will it really cost to finish - or fix?

This is where the previous eight questions meet. Convert the remaining work and identified risks into engineer-months, other discipline costs and calendar time. Use the studio’s demonstrated throughput, not an idealised velocity from the pitch.

Include the work created by the transaction: retaining key people, replacing dependencies, documenting ownership, bringing security up to the buyer’s standard, changing backend operations and satisfying any partner approvals. A low purchase price does not make those costs disappear; it merely puts them on another line.

I prefer a range with assumptions to one confident number. The range should show which findings can move the answer most, because those are the items worth resolving before close.

One more thing to read

Read how the studio responds to diligence. Prompt, specific answers with named owners are a good operating signal. So are sensible admissions: “We do not know yet; Sarah is checking the contract and will answer on Thursday.”

Beautiful documents followed by contradictory interviews are a signal too. Diligence is partly about the assets and partly about whether the organisation can find out what is true.

Nine good answers will not make an acquisition safe. They should, at least, make the risks recognisable enough to price and manage - which is a more useful ambition.