Bringing an external team into a running Unity production is a handover problem before it is an engineering problem. The new developers need to know what is safe to change, what is already fragile and which work actually matters to the release. A project audit is supposed to answer exactly that. Too often it produces a long list of observations instead: "too many singletons", "old packages", "performance could be better". None of those can be scheduled, estimated or accepted.
This guide is for technical leads and producers who are about to commission an audit, or to evaluate one. The question it answers: how does an audit become a ranked priority list and a work package that can be handed over safely?
When an audit is the right first step
An audit costs time before any visible progress, so it should be justified by uncertainty, not by habit. It is usually the right first step when:
- The project was inherited. The original team has left or moved on, and nobody can confidently say which systems are load-bearing.
- Performance misses the target hardware, but nobody knows whether the cause is content, code, rendering or architecture.
- The project has become slow, unstable or hard to change. Small features take weeks, merges break scenes, and the same bugs return.
- A prototype needs to become a production. The code proved the game, but it was not built to absorb content or a larger team.
- A producer or publisher has to decide whether to invest further and needs a technical basis for that decision.
If the problem is narrow, reproducible and its cause is already understood, a focused fix is often cheaper than a full audit. A good partner will say so. The scope of the audit should match the size of the uncertainty.
What to provide before the audit starts
The quality of an audit depends on its inputs. Prepare these before the external team starts, and treat anything you cannot provide as a finding in itself.
| Input | Why it matters |
|---|---|
| Unity version and render pipeline | Determines upgrade paths, package compatibility and which tooling is available. |
| Target platforms and representative hardware | Performance findings are only meaningful on the hardware players will use. |
| A current build and the steps to produce it | Shows whether the build is reproducible outside one developer's machine. |
| Reproducible issues with steps | Turns "it stutters sometimes" into a scenario that can be measured before and after. |
| Existing profiles, crash logs and bug reports | Saves time and reveals what the team has already ruled out. |
| Scope and ownership | Which areas the audit covers, who owns each system, which branches are active and what the code-review rules are. |
| The decision the audit must support | For example: "Can an external team take over combat and AI without blocking content production?" |
The last row is the most often missing. An audit without a decision to support tends to grow into an unprioritised inventory.
What the audit should review
A Unity audit before co-development should cover the areas where an incoming team is most likely to cause or meet problems. The depth per area depends on the decision above.
| Area | Questions the audit should answer |
|---|---|
| Architecture | How are assemblies and dependencies organised? Where are the boundaries between gameplay, networking, presentation and data? Which systems are tightly coupled? |
| Packages and plugins | Which packages and versions are used? Are any forked, embedded or abandoned? What blocks an upgrade? |
| Scenes and prefabs | How are scenes loaded and owned? Where do merge conflicts and broken serialized references come from? |
| Data flows | Where is game state owned? How do configuration, save data and, if relevant, network state move through the game? |
| Tooling | Which editor tools, import rules and data validation exist? Where can designers or artists break the build without noticing? |
| Build pipeline | Can a clean machine or CI produce every target build, including headless server builds if the game has them? Which steps are manual? |
| Performance | What do CPU, GPU, memory, loading and garbage-collection profiles show on representative target hardware, in a scenario that can be repeated? |
The performance row deserves a specific warning. Profiles from the editor or from a high-end development PC are useful for orientation, but they are not evidence for a mobile VR headset or a mid-range player PC. Techniques such as Burst, native containers or data-oriented layouts belong in the intervention column only when a measured workload justifies them. Our team used them on VOXSYS, a mobile VR shooter that targeted 90 FPS (work delivered by current team members in their previous VR Storm Studio roles); the lesson there was to measure first and optimise the proven bottleneck, not the suspected one.
The build pipeline row matters for the same reason. On Bean stalker, a procedural VR world built by an 18-person cross-functional team, tools, validation and build automation mattered as much as the generation algorithm, because content creators needed fast feedback and the release team needed repeatable results.
What every finding must contain
This is the core of a useful audit. Each finding should be a self-contained unit that a producer can schedule and an engineer can verify. Use this template:
| Field | What it contains | Weak version | Useful version |
|---|---|---|---|
| Problem | One concrete issue, scoped to a system or workflow. | "Architecture is messy." | "Enemy spawning allocates and instantiates during combat." |
| Evidence | How it was observed: profile, log, code reference, reproduction steps. | "We noticed it." | "Capture on target hardware, scenario X, frames N–M; code path in SpawnController." |
| Player / business impact | What players feel or what production loses. | "Bad for performance." | "Visible hitch at the peak of every combat wave." |
| Priority | Ranked against other findings by impact and risk. | "High" everywhere. | "P1: blocks the agreed release quality bar." |
| Proposed intervention | What to change, and whether it is a quick fix, incremental refactor or restructuring. | "Refactor spawning." | "Pool enemy prefabs, remove per-spawn allocations, add a regression scenario." |
| Acceptance criteria | How everyone will know it is done, measured the same way as the evidence. | "Should be faster." | "Same scenario, same hardware: no frame over the agreed budget during the wave." |
Two fields are often skipped and they are the ones that make the audit actionable. Evidence makes the finding reviewable by your own team. Acceptance criteria turn the finding into a work item with a clear end, and they become the review standard when the work is handed back.
Quick fix, incremental refactor or restructuring
Each proposed intervention should be classified, because the three types carry very different risk for a production that keeps shipping content while the work happens.
| Type | Typical fit | Production risk | How it is verified |
|---|---|---|---|
| Quick fix | A local, well-understood cause: a hot allocation, a missing validation, a manual build step. | Low; touches one system. | The original reproduction and measurement, before and after. |
| Incremental refactor | A system that works but resists change: tangled dependencies, unclear state ownership. | Medium; needs a testable boundary and a migration plan around active content work. | Tests around critical rules, unchanged behaviour, plus the agreed acceptance criteria. |
| Larger restructuring | The evidence shows the root cause is structural, for example state ownership that cannot support a new requirement. | High; competes with features and needs a staged plan. | Staged milestones, each with its own acceptance criteria. |
A trustworthy audit does not jump to a rewrite. Most findings should land in the first two rows. When a restructuring is proposed, it should come with the evidence that smaller interventions will not work and a plan that does not freeze the rest of production.
From audit to co-development handover
The audit becomes useful when its findings turn into a work package an external team can own. Before implementation starts, agree on four things.
Responsibilities. Typically the client owns repository access, branching rules and code-review policy, product priorities and acceptance of delivered work, and the target hardware and platform requirements. The external team owns the engineering quality of what it delivers, reproducible measurements for every optimisation claim and clear ownership boundaries with your internal developers.
Dependencies. For each finding in the package, list what it depends on: other findings, content deliveries, a package upgrade, access to a device, a decision from design. Dependencies that are not written down become delays that nobody owns.
Review. Decide who reviews pull requests, how often progress is demonstrated and what happens when a finding turns out larger than estimated. The acceptance criteria from the audit are the review checklist.
Handover. Define what comes back when the work is done: merged code, tests around the changed rules, documentation, updated tooling and the before-and-after measurements. The goal is a codebase your team can keep maintaining, not a dependency on the external team.
We describe the different ownership models, from a bounded workstream to embedded engineers, on the game development page. How we approach audits of existing Unity projects specifically is covered on the Unity game development page.
Illustrative sample finding
Illustrative example. The finding below is hypothetical. It does not describe a real client or project and contains no measured values. It shows how the template looks when it is filled in.
| Field | Content |
|---|---|
| Problem | During combat waves, enemies are instantiated from prefabs at spawn time, and the spawn logic allocates temporary collections every time an enemy spawns. |
| Evidence | CPU profile captured on the agreed target hardware, in a repeatable scenario (a fixed save at the start of wave three). Frames with spikes show instantiation and garbage collection in the spawn code path. The code location is referenced. |
| Player / business impact | Players see a hitch at the most intense moment of each wave. On a VR target the same hitch would also be a comfort problem. It appears in reviews and playtest notes as "stutter". |
| Priority | P1: it affects every session and blocks the agreed performance bar for the next milestone. |
| Proposed intervention | Quick fix: pre-warm a pool for the enemy prefabs used in the wave and remove per-spawn allocations from the spawn path. Add the scenario to the regular performance check so it cannot silently return. |
| Acceptance criteria | In the same scenario on the same hardware, no frame during the wave exceeds the agreed frame-time budget, and the spawn path allocates no managed memory per spawn after warm-up. The before-and-after captures are attached to the pull request. |
Note what the example does not contain: a promised percentage improvement. The acceptance criterion is tied to the project's own budget and measured the same way as the evidence. That is what makes it reviewable.
If your current production is a networked game, the same template applies to findings in server builds and state ownership. In Bad Goons, our current original IP in active development, the Unity 6 client, FishNet realtime layer, voxel simulation and Linux dedicated servers are treated as separate production systems, and that separation is exactly what an audit should look for or recommend. The VOXSYS case study shows the performance side of the same discipline.
Checklist for evaluating an audit proposal
Use these questions before you approve an audit, and again when you receive the report.
- The proposal names the decision the audit will support, not just the areas it will look at.
- The required inputs are listed: Unity version, render pipeline, target platforms and hardware, build steps, reproducible issues, existing profiles, scope and ownership.
- Performance work is planned on representative target hardware, in repeatable scenarios.
- The review covers architecture, packages, scenes, data flows, tooling, the build pipeline and performance, or explains why an area is excluded.
- Every finding will include problem, evidence, player or business impact, priority, proposed intervention and acceptance criteria.
- Findings are ranked against each other, not all marked "high".
- Each intervention is classified as quick fix, incremental refactor or larger restructuring, with its production risk.
- Any restructuring proposal includes the evidence that smaller changes will not work and a plan that does not freeze content production.
- The report ends with a work package: responsibilities, dependencies, review process and handover deliverables.
- Optimisation claims will be backed by before-and-after measurements in the same scenario.
- Your own team can verify every finding without the external team present.