How a Non-Technical Founder Can Check a Unity Build

You can evaluate a Unity project as a non technical founder by checking what the team can show you, not what the code says. Ask for a fresh build on a cheap phone, the project history, a one-click build process, and a short tour of the project folder. Ten checks in one afternoon cover most of the risk.

Why this check is worth an afternoon

Your seed money is paying for two things: a game, and a codebase someone else can keep working on. The game is easy to judge because you can play it. The codebase is invisible until something goes wrong, usually when you change studios or hire your first engineer.

A short check every milestone gives you an early read. It also gives you something concrete to tell your board when they ask whether the build is in good shape.

The goal is not to grade the code. The goal is to find out whether the project could survive without the people who wrote it.

The ten checks, in order

Run them roughly in this order. The first five need nothing but a phone and a call.

1. Install a fresh build on a cheap Android phone. Not the studio's test device, yours. Note the install size, the time to the first playable screen, and whether it stutters.
2. Ask where the project lives. The answer should be a version control service such as GitHub, GitLab, Plastic SCM (now Unity Version Control) or Perforce. A zip file in a shared drive is a warning.
3. Ask for access to that repository in your own name. You own the code under most work-for-hire contracts. You should be able to see it without asking each time.
4. Look at the commit history. You do not need to read the changes. Look for small, regular commits with readable messages from more than one person.
5. Ask how a build is made. A healthy answer is one command or one button, ideally automated. A worrying answer is "only Sam knows how".
6. Check the Unity version. It sits in ProjectSettings/ProjectVersion.txt. It should be a long-term support (LTS) release, and the team should know why they chose it.
7. Open Packages/manifest.json. It lists every package the game uses. Ask what each unfamiliar one does. Every answer should be short.
8. Ask for a five-minute folder tour. Scenes, scripts, art, and third-party code should live in clearly named folders, not in one pile.
9. Ask what happens when the game crashes. There should be a crash reporting tool and someone who reads it.
10. Ask for the list of third-party SDKs. Ads, analytics, attribution. Each one carries a cost, a privacy duty and an update cycle.

What each answer tells you

The checks are simple. Reading the answers is where judgement comes in. This table covers the usual responses.

None of the warning answers is a disaster on its own. Two or three together mean you should get a technical second opinion before the next payment.

Questions to ask the studio directly

You will learn as much from how the team answers as from what they say. A confident team explains in plain words and does not mind the questions.

• What would a new engineer need to build this project on day one?
• Which part of the code are you least happy with, and why?
• What would break if we upgraded Unity next quarter?
• Where are the game's settings and balance numbers stored?
• If you left tomorrow, what would we be missing?

The second question is the most useful. Every real project has a messy corner. A team that names it is a team that knows its own work.

When to bring in a technical reviewer

This founder-level check is a filter, not a full audit. It tells you when to spend money on a proper look. If your checks raise two or more flags, or you are about to change studios or raise again, a paid review is worth it.

We cover what a full review looks like in our guide to technical due diligence on a game build. Expect a reviewer to open the project, build it, run the profiler on a real device and read a sample of the code.

What to ask the reviewer for

Ask for a short written report in three parts: what is solid, what is risky, and what it would cost to fix the risky parts. That last part is the one your board will care about.

What we would do

We would run the ten checks at every milestone, not once. Projects drift. A clean repository in month one can turn messy by month four if the team is rushing.

We would also put repository access and a documented build process into the contract from day one. Asking for them later feels like an accusation. Asking up front just looks like good practice, and any studio worth hiring will agree without fuss.

If a studio resists either request, that tells you more than any code review could.

The short version

• Judge what the team can show you: a build, a repository, a build process and a folder tour.
• Test on your own cheap Android phone, not the studio's device.
• You should have repository access in your own name from the start.
• Two or three warning answers together mean it is time for a technical second opinion.
• Ask which part of the code the team likes least. Honest answers are a good sign.

If you would like a second pair of eyes on a Unity project before your next milestone payment, we are happy to take a look.

Related reading: Technical Due Diligence: How to Audit a Game Build You Did Not Write, Why a Technical Audit Saves More Than It Costs, How to Give Feedback on Game Builds Without Derailing Anything