Technical Due Diligence: How to Audit a Game Build You Did Not Write

Most of what you need to know about a game build is visible without reading code. Can a stranger build it from a clean checkout, does the source control history show real work, are the third-party licences safe, and does the structure match the scope. Those four questions catch nearly every serious problem.

Why this matters

Two situations put a founder in front of a codebase they did not commission. Taking over from a previous team, and diligence before an acquisition or an investment.

Both are moments where a wrong read is expensive and slow to discover. A project that cannot be built by anyone except its original author is a liability that looks exactly like an asset from the outside.

The reassuring part is that you do not need to be an engineer to run the first pass. The strongest signals are process signals.

What you are actually checking for

Four risks matter, in this order.

1. Continuity risk. Can somebody other than the original author work on this.
2. Legal risk. Does anything in the project prevent you from shipping or selling it.
3. Quality risk. Will this fall over as soon as it meets real players.
4. Cost risk. How much work sits between this build and the thing you actually want.

Notice that code elegance is not on the list. Ugly code that ships and can be handed over is worth more than beautiful code only one person understands.

The question is never "is this good code". It is "what will it cost me to own this".

Can somebody else build it from a clean checkout

This is the single most informative test available, and it takes an afternoon.

Ask for the repository. On a machine that has never seen the project, clone it and follow whatever setup documentation exists. Then build it for a device.

Watch what happens.

• It builds with documented steps. Strong signal. Rare, and worth a lot.
• It builds after some undocumented fiddling. Normal. Write down what was missing.
• It only builds on the original developer's machine. Serious finding. You are buying a person, not a project.
• Assets are missing from the repository. Common and fixable, but it tells you the handover was never rehearsed.

If a build takes more than a day to reproduce, treat the estimate for everything else as optimistic.

Source control history, and what a bad repo looks like

You can read a repository history without reading any code, and it is remarkably revealing.

The absence of source control entirely is a finding on its own, and it changes the price of everything that follows.

Third-party assets and licence risk

This is where the genuinely dangerous problems hide, because they are invisible until they are not.

Ask for a list of every third-party asset, package, plugin, and font, with the licence for each. A team that cannot produce this list has not been tracking it.

Then look for four specific things.

• Store assets used beyond their licence terms, particularly art used in a way the licence excludes.
• Code copied from tutorials or forums without a clear licence.
• Fonts, which are licensed far more narrowly than most people assume.
• Music and sound effects, where "royalty free" frequently means something more limited than it sounds.

Anything unresolved here should be fixed before money moves. Ownership of the rest is a separate question, covered in Who Owns Your Game IP.

Architecture smells a non-engineer can spot

You can find real structural problems by looking at the project rather than the code.

• One enormous script file. Open the scripts folder and sort by size. A single file of several thousand lines usually means the logic cannot be changed safely.
• No folder structure. Everything in one directory means nobody expected anyone else to work in it.
• Duplicate assets with names like "final" and "final2". The pipeline is manual and error-prone.
• Hard-coded values everywhere. Ask whether the team can change difficulty without a new build. If the answer is no, iteration will be slow and expensive.
• No test scenes. Ask how a feature is checked in isolation. Silence is an answer.
• Secrets committed to the repository. Keys and passwords in source are both a security issue and a signal about process.

The 90-minute audit you can run yourself

Run these in order. Stop early if something serious surfaces.

1. Minutes 0 to 15. Get repository access and clone it. Note how long access takes to arrange.
2. Minutes 15 to 30. Read the history. Look at commit frequency, messages, and contributors.
3. Minutes 30 to 45. Open the project structure. Sort scripts by size, scan the folders, look for the smells above.
4. Minutes 45 to 60. Ask for the third-party asset and licence list. Absence is the finding.
5. Minutes 60 to 80. Attempt a build on a clean machine, following the documentation as written.
6. Minutes 80 to 90. Write down the three things that would cost the most to fix.

That last step is what turns an audit into a negotiating position.

When to pay for a real code review

The ninety-minute pass finds process problems. It will not find performance problems, security problems, or the kind of design decision that limits the game two years from now.

Bring in an engineer for a paid review when the amount at stake is meaningful, when the build is the core of an acquisition, or when the first pass raised something you cannot evaluate. A review of a few days costs a fraction of inheriting a rebuild.

Ask the reviewer for a written list of findings ranked by cost to fix, rather than a general opinion on quality.

What we would do

Run the clean checkout test first, always. It is the highest information per hour of anything on this list, and its result reframes everything else.

Treat the licence list as a gate rather than a line item. Everything else can be priced and scheduled. An unlicensed asset in a shipped game is a different category of problem.

Then write the three-item cost list and use it. Diligence that does not change the price or the plan was a formality.

The short version

• Four risks matter: continuity, legal, quality, and cost to own.
• The clean checkout build test is the most informative ninety minutes available.
• Repository history tells you how the work really happened.
• The third-party asset and licence list is a gate, not a detail.
• Structural smells are visible in the project layout without reading code.
• Pay for an engineering review when the stakes justify it, and ask for findings ranked by cost.

Run the ninety-minute pass before you sign anything or take over anything. If you would rather have an engineer do it with you, get in touch.

Related reading: What Investors Mean When They Ask About Your Tech Stack, Rescuing a Stalled Game Project, and Ten Questions to Ask a Game Studio Before You Sign.