Package format
Define whether the first tester build is a zip archive, unsigned installer, signed installer, or manual build handoff. The public site should describe the chosen format before testers receive access.
Unlisted planning page
The tester app build needs its own release discipline.
This is a direct-link planning surface, not part of the public buyer journey. It defines what must be true before the first tester package is distributed.
Release package stages
What the first tester package must define.
This is the bridge between static-site readiness and actual app testing. The build, license behavior, download access, and support loop should be testable as one path.
Build identity
Every tester build needs a version, release date, supported platform note, checksum, known-issues note, and rollback guidance.
Download access
Download access should be tied to selected-tester entitlement and should not appear as a public installer button until intentionally released.
Install guidance
The install path should explain local folders, helper-tool assumptions, dependency boundaries, and how to preserve project data before replacing builds.
Activation states
The app should make success, invalid code, expired access, activation-limit reached, offline grace, and reset/support states clear enough for testers to report accurately.
Feedback loop
Tester reports should include app version, platform, package format, activation state, download path friction, and whether installation was blocked or only confusing.
Selected-tester package checks
- Tester can identify which build they received.
- Tester can verify the package or archive checksum if asked.
- Tester can find version and build information inside the app or release notes.
- Tester can install or unpack without developer intervention.
- Tester can understand whether helper tools are bundled, external, or manually configured.
- Tester can activate or report exactly why activation failed.
- Tester can preserve project data before replacing the build.
- Tester can report bugs with package version, operating system, and reproducible steps.
Do not ship through the public static site
- Installer binaries in the website repo.
- Private download URLs in public pages or metadata.
- License signing secrets or provider credentials.
- Real coupon codes or tester records.
- Model weights, ComfyUI bundles, FFmpeg binaries, custom nodes, or third-party assets without a separate distribution policy.
- Customer project files or private creative material.
Recommended first package assumption
Start with a versioned tester archive unless installer signing is ready.
A signed installer is cleaner for retail, but a small selected-tester cohort can validate the path with a versioned archive if the release notes, checksum, setup instructions, activation states, and support loop are clear. The final choice should be recorded before selected-tester invites go out.