Developer design-partner pilot

The next milestone is not another extractor. It is evidence that developers can run Xila safely, understand the output and act on it without losing time to false positives.

Who to recruit

Recruit ten developers from small or mid-sized teams shipping an online Unity, Godot or WebGL game. Aim for a mix of engines, team sizes, released and pre-release projects, and CI providers. Do not recruit only security-minded friends.

The default pilot is a 30-minute call or screen share. The developer runs Xila locally. Xila receives no build, report or telemetry.

Interview before the demo

Ask without describing Xila first:

1. Walk me through the last step before you upload a game build.
2. What security problem has reached production or delayed a release?
3. Have you ever checked a shipped build for credentials or backend settings?
4. Who owns Firebase, PlayFab, Nakama, Supabase or cloud configuration?
5. What happens when CI reports a security warning developers disagree with?
6. Which build files may never leave your environment?
7. What evidence would make you trust an offline scanner?
8. Would you add a non-blocking scan to CI? What would stop you?

Record exact words, engine/platform, existing process and severity of the pain. Do not count a polite “interesting” as validation.

Pilot procedure

1. Explain that Xila is static, offline and does not validate credentials.

2. Show docs/trust.md, especially supported surfaces and external-module limits.

3. Let the developer install from source or a checksummed release.

4. Run non-blocking first:

   xila scan ./Build --format json --out xila.json
   

5. Review every critical/high finding together. The developer labels it actionable, valid-but-accepted, false positive or unclear.

6. Check the component inventory for expected assemblies/configuration and note unsupported or missing content.

7. If the report is useful, create a baseline and offer a non-blocking CI run.

8. Ask the developer to run it again on the next build without assistance.

Never request a raw report. Collect sanitized rule IDs and aggregate counts. If a reproduction is needed, jointly create a synthetic fixture.

Measurement sheet

For each pilot record:

• install method and minutes to first report;
• engine, target platform and approximate build size;
• expected versus extracted component classes;
• critical/high findings by label;
• lower-severity findings sampled and labeled;
• crashes, timeouts and peak memory if observed;
• whether remediation was understood without explanation;
• whether the developer ran Xila again or added it to CI;
• exact objection or trust concern.

Calculate precision as actionable or valid / all reviewed findings, separately for critical/high and lower severities. Never claim a detection rate from the planted sample repository; it measures regression coverage, not real-world accuracy.

Trust milestone

Before expanding into Audit or adding broad new engine support, reach all of:

• 20 interviews, with at least 10 describing build-secret or backend exposure as a real problem;
• 10 authorized real builds scanned locally by their owners;
• every critical/high result labeled, with at least 90% precision on that pilot set;
• zero unredacted credentials in reports or logs;
• median time to first report below 10 minutes;
• five teams run Xila twice, and at least three keep it in CI for four weeks;
• one outside issue or contribution completed through the public workflow.

If precision misses the target, stop adding rules and fix the noisy ones. If coverage misses expected content, improve that extractor before adding another engine. If developers will not run a second scan, investigate workflow cost and report usefulness before building cloud products.