Unity Asset QA Checklist Before Release, Handoff or Marketplace Submission

Most asset problems are cheap before delivery and expensive after delivery.

A missing material slot takes seconds to fix when the artist still has the project open. It becomes a support ticket after a customer downloads the package. An unexpected scale factor is easy to catch before a prefab is placed fifty times. A missing script reference is obvious in an audit and annoying in a client build.

This checklist is designed for a final asset-level QA pass before:

• handing work to another developer;
• delivering outsourced art;
• submitting a marketplace package;
• creating a release branch;
• archiving a milestone.

You can run part of this automatically with the free Unity Asset Preflight Auditor, then review the findings in context.

Start with a clean import

Before reviewing an asset, test how it behaves when imported cleanly.

If possible:

1. use a fresh test project or isolated folder;
2. import the delivered files;
3. wait for all importers to finish;
4. check Console errors and warnings;
5. open the main prefab or scene without relying on hidden local dependencies.

An asset that only works because your original project already contains a material, script or texture is not actually self-contained.

Check model scale

Scale problems are one of the easiest ways to create downstream friction.

For each important mesh, verify:

• expected real-world size;
• Transform scale at placement time;
• importer Scale Factor;
• orientation;
• pivot location;
• whether the same convention is used across the set.

A door, table and character do not need identical dimensions, but they should make sense relative to the same world scale.

If one FBX needs unusual importer scaling, document why.

Check pivots for how the object is used

The “correct” pivot depends on function.

Examples:

• doors usually need a pivot at the hinge;
• modular walls usually need a predictable corner or grid pivot;
• handheld weapons need a usable grip reference;
• floor props often work best with a base-centered pivot;
• rotating machinery needs a pivot on the real rotation axis.

A visually perfect mesh with a bad pivot can be frustrating to use hundreds of times.

Review Read/Write settings

Unity mesh Read/Write can increase memory usage because CPU-accessible mesh data may be retained.

That does not mean Read/Write is always wrong.

Keep it enabled when runtime systems actually need mesh data. Otherwise, treat it as something worth reviewing.

The Asset Preflight Auditor can flag readable models so you can inspect them instead of searching manually.

Verify material slots

Open every main prefab and inspect renderers.

Look for:

• empty material slots;
• unexpected duplicate materials;
• materials referencing textures outside the package;
• incorrect shader assignment;
• transparent materials using the wrong surface mode;
• unnecessary material count on simple props.

A missing material slot should normally be treated as a release-blocking error.

Check texture source size

Do not assume a 4K or 8K texture is justified because the source exists at that size.

Ask:

• How large is the object on screen?
• Is the texture reused?
• Does the target platform need this resolution?
• Are mipmaps appropriate?
• Is compression configured?
• Are multiple maps unnecessarily storing the same information?

The goal is not to make every texture small. The goal is to make texture cost intentional.

Confirm texture map interpretation

A texture can look “almost right” while still being imported incorrectly.

Check:

• normal maps are imported as normal maps;
• color textures use the intended color space;
• packed masks use the documented channel order;
• alpha is used only where needed;
• emissive maps match the material setup;
• roughness / smoothness conventions are not reversed accidentally.

If your package uses packed textures such as ORM, document the channels.

Decide whether mipmaps are appropriate

Mipmaps are useful for most world-space textures because they reduce aliasing and improve sampling at distance.

They may be unnecessary for some UI, lookup or special-purpose textures.

Do not disable them globally just to save space. Review by use case.

Check prefab missing references

Missing script references and broken object references are serious handoff problems.

Inspect:

• missing MonoBehaviours;
• null materials;
• missing animation controllers;
• empty required fields;
• references to assets outside the delivered folder.

If a prefab intentionally has an unassigned field that the user must configure, document that clearly.

Review collider expectations

A renderer without a collider is not automatically wrong.

The question is whether the object is expected to participate in physics or navigation.

Check:

• environment blockers;
• interactive props;
• doors;
• floors / stairs;
• pickups;
• large decoration the player can approach.

For static visual-only assets, no collider may be correct.

For marketplace assets, it is useful to state whether collision is included rather than making customers guess.

Test modular pieces on the real grid

Modular assets should be tested by assembly, not viewed one at a time.

Build a quick test:

• wall + wall;
• wall + corner;
• wall + door;
• floor + wall;
• roof + wall;
• repeated pieces across several grid cells.

Look for:

• tiny gaps;
• overlapping geometry;
• inconsistent pivots;
• mismatched dimensions;
• visible shading seams;
• z-fighting.

The best modular QA test is trying to build something with the set quickly.

Check normals and shading

Common shading problems include:

• flipped normals;
• unexpected hard edges;
• inconsistent smoothing;
• visible seams;
• broken tangents;
• normal-map artifacts.

Inspect under more than one light direction.

A problem hidden in the preview lighting may become obvious in a customer's scene.

Check triangle count in context

There is no universal correct triangle count for a prop.

Review cost relative to:

• target hardware;
• screen size;
• number of instances;
• animation / deformation;
• overdraw;
• material complexity.

A hero prop used once can justify more geometry than a small clutter object repeated 500 times.

The QA question is not “is this low-poly?” It is “is the geometry appropriate for how the asset is used?”

Review LODs if they are included

If LODs exist, test:

• transition distances;
• silhouette preservation;
• material consistency;
• missing submeshes;
• pivot consistency;
• whether LOD naming is predictable.

Do not include meaningless LODs just to advertise a larger feature list.

Check animation assets in-engine

For animated assets, verify:

• expected clip names;
• clip start and end frames;
• looping behavior;
• root motion expectations;
• skeleton references;
• retargeting setup if relevant;
• playback speed;
• transitions between common clips.

A list of animations is not enough. They need to behave correctly in the target runtime.

Search for duplicate and temporary files

Before packaging, remove obvious production leftovers:

• backup copies;
• old FBX exports;
• temporary textures;
• unused materials;
• screenshots that do not belong in the asset;
• test scenes with broken dependencies;
• files named final2, copy, old, or temp that are not part of the intended deliverable.

Do not delete blindly. Confirm references first.

Use predictable names

Clean naming makes QA faster because related files become searchable.

For example:

SM_GothicDoor_A

MAT_GothicDoor

T_GothicDoor_BaseColor

T_GothicDoor_Normal

If your project needs help standardizing names, use the Game Asset Naming Convention Generator and write the chosen convention into your handoff documentation.

Test package independence

A commercial or outsourced asset should not depend on accidental files in the creator's full project.

Check for references to:

• local shaders not included in delivery;
• materials outside the package;
• scripts from unrelated systems;
• textures in personal test folders;
• missing packages or plugins.

If an external dependency is required, state it clearly before purchase or handoff.

Include a small README

A useful README can prevent many support messages.

Include:

• Unity version tested;
• render pipeline;
• installation location if important;
• how to open the demo or prefab;
• included formats;
• whether collision is included;
• whether animations are included;
• any required third-party dependency;
• contact / support route.

Documentation does not need to be long. It needs to answer the first questions a new user will ask.

Run an automated preflight, then use human judgment

Automated tools are good at finding predictable patterns. They are bad at understanding intent.

A tool can flag:

• Read/Write enabled;
• unusually large textures;
• missing materials;
• missing scripts;
• colliders absent from renderable prefabs.

Only a human can decide whether those findings matter for this asset.

The free Unity Asset Preflight Auditor intentionally does not auto-fix anything. It reports issues so the developer stays in control.

Export a report for handoff

A CSV report is useful when several people need to review the same package.

It creates a simple record of:

• severity;
• asset path;
• issue type;
• rule;
• details.

That is easier to review than screenshots scattered across chat.

If you want the exported findings prioritized, the Unity Asset QA Report Review is a fixed-scope $25 review that groups issues by severity, checks context and produces a practical fix order.

A final release checklist

Before delivering, confirm:

• Assets import without critical Console errors.
• Scale and pivots are intentional.
• Material slots are complete.
• Texture types and sizes are appropriate.
• Prefabs have no missing scripts.
• Required colliders are present.
• Modular pieces snap correctly.
• Shading and normals are clean.
• LODs and animations behave correctly if included.
• Temporary and duplicate files are removed.
• Names are consistent.
• External dependencies are documented.
• README / usage notes are included.
• The package works in a clean test environment.

QA is not a final polish step. It is part of the product.

A few minutes spent catching predictable issues before delivery can save hours of support, rework and buyer frustration later.

Useful next steps: run the Unity Asset Preflight Auditor, standardize names with the Game Asset Naming Convention Generator, or prepare outsourced work with the 3D Asset Brief Generator.