A practical Unity project audit guide

Taking over a Unity project? What to check before starting over.

By Artem Shkabura · 7 September 2026

A stalled Unity project can look worse than it is. A missing SDK, undocumented build step or abandoned service may hide a usable product. Equally, a convincing demo can conceal serious release problems.

As a founder or producer, you need to know what the next investment can realistically achieve. I start by asking what you want to release, what already works and which problems could prevent completion. A brief outline is enough for the first conversation; we can agree an NDA before sharing sensitive material or source-code access.

Preserve what you inherited

Keep the repository history, the last working build and any setup notes. Record the Unity Editor version and target platform before opening the project in another version. Preserve the original and investigate on a separate working copy.

The first useful deliverable is a repeatable build: another machine can follow documented steps and produce an application that runs. If that fails, capture the exact blocker and missing dependency. “Does not build” is a finding to investigate, not enough evidence for a rewrite.

Unity recommends backing up before upgrades and assessing whether their benefits justify the effort. I use that same discipline before changing an inherited project’s baseline.

Unity: Upgrade your Unity project

Check the tools, services and accounts the project needs

I check the Editor version, render pipeline, Unity packages, Asset Store assets, native plugins and external SDKs. The review also includes build tools, backend environments, signing access and who controls the required accounts.

For each critical dependency, establish its version, availability, compatibility and owner. A plugin maintained through undocumented local edits needs different treatment from one that can be installed unchanged.

Keep the package manifest and lock file with the project. Unity’s lock file records resolved package dependencies and should be versioned to reproduce the same package set across machines. An unavailable service or missing source may determine the recovery scope more than the age of the C# code.

Unity: Dependency resolution and lock files

Test performance on the intended devices

“It runs smoothly on my computer” does not establish mobile or headset readiness. I choose representative hardware and repeatable scenarios: startup, a busy gameplay moment, a scene transition and a longer session where relevant.

I look for CPU or GPU pressure, memory growth, loading delays and recurring allocations, then connect findings to a player-visible problem. Record the device, build version, settings and steps so comparisons are meaningful.

Unity recommends profiling on the intended platform. Editor Play Mode shares resources with the Editor and does not accurately reflect device performance. Development builds support connection to the Unity Profiler. Profiling guides diagnosis; I also check the proposed fix in the intended release configuration before treating it as resolved.

Unity: Profiling your application

Check saved progress, purchases and analytics

A successful launch is only one part of compatibility. Existing players may have saved progress, unlocked content, purchases or server-side state.

I trace where that data lives and test representative old saves against the proposed changes. Check interrupted loading, missing data and migration failures. Agree what must survive, what can change and how recovery works before altering formats or identifiers.

Then follow a complete progression path: start, earn or unlock something, save, restart and continue. Verify the associated analytics events, including their meaning and version context. If historical tracking is unreliable, the next release may establish a measurement baseline; it cannot automatically prove that retention improved.

Test the biggest unknown in a small working example

Before estimating a major code change or rebuild, I agree a small test: the question it must answer, the work limit and what counts as a successful result.

For example: can one representative level load an existing save, complete a gameplay loop, send the expected events and run within the agreed performance budget on the target phone?

The test should include the systems most likely to prevent release. Rebuilding an isolated menu tells us little about player progress or platform services. Set the work limit in advance and record what the test established, what failed and what remains unknown.

Choose the next step from the findings.

The recommendation should explain what the review found, why it matters and what work to do next.

Finish

The main game works, and the remaining work can be clearly listed and estimated.

Next step: Fix the problems preventing release and test the agreed features.

Refactor

Specific systems repeatedly cause failures or obstruct necessary changes.

Next step: Improve one part of the code and check that connected features still work.

Rebuild

The existing code cannot reasonably support the required features, even after practical repair options have been considered.

Next step: Test the replacement approach and plan how to transfer existing player data.

A small paid project review can help you decide what to do next. We agree the question, required access, work limit and deliverables before starting. You receive a working build or an explanation of what prevents it, a prioritized list of findings and a proposed next step with its assumptions clearly stated.

For a concrete example of interconnected gameplay, saves and progression, explore Polar Station Survival—a game with many connected systems where I was the sole Unity developer.