Build Delta Guard compares a candidate Unity build with an accepted baseline, then posts the size, memory, shader, bundle, and duration changes your team actually needs to investigate.
Only policy-relevant changes are raised.
A compact PR report with budget checks and the highest-confidence asset attribution available from the build artifacts.
The first pilot uses the subset that matches your workflow. The rest stay out of the way until they earn their place.
Executable, AAB, APK, IPA, Addressables, and bundle changes against an accepted baseline.
Texture, audio, scene, and other asset deltas with source attribution where the build data supports it.
Surface sudden variant growth before it becomes a build-time or runtime surprise.
Flag likely duplicated assets across bundles or build outputs with the evidence attached.
Track wall-clock regressions by target and build configuration instead of relying on CI intuition.
Apply absolute and relative thresholds per platform, branch, and metric.
No platform migration and no quarter-long rollout. We start with one decision your team currently has to make without enough evidence.
Agree on one repository, target, baseline, CI job, and the signals that should be visible.
Wire a read-only analysis step into the current workflow and produce an example report.
Run it against representative changes, tune noise, and decide whether the next scope is justified.
No. It reviews build-level change signals. Runtime profiling remains a separate workflow, and any measurable runtime budgets need an agreed, reproducible test scene.
The pilot is designed to run in your CI. It reads the build inputs and outputs needed for the agreed checks; the default model does not upload your repository to XeSoft.
A first report on one build target, connected to one existing CI workflow, with an agreed subset of budgets. We then use the result to decide whether a broader rollout is worthwhile.
We will tell you what a useful one-week pilot can cover—and what it cannot.
outreach@xesoft.dev ↗