Publish your first product
Prepare a release, document its status and choose an appropriate distribution channel.
What this step is for.
Publishing is a separate engineering stage. Freeze a release candidate, run a release checklist, create the distribution artifact, document known limitations and only then publish through the appropriate channel.
Keep the scope small enough that you can inspect the result yourself. AI can accelerate the work, but it should not erase the distinction between a suggestion, a changed file, a successful build and a verified product.
Take one concrete action.
Create a mock release folder containing the artifact or demo, version number, changelog, test checklist and rollback copy. Do not publish a practice artifact as production software.
Create a complete offline practice release
This first release stays offline so it does not depend on a hosting provider's changing interface. Step 12 ended with a clean Git commit in my-studio-site. Open PowerShell in that source folder and run git status; it must say the working tree is clean. Run git rev-parse --short HEAD and copy the short build identifier.
Create a sibling folder named release-v0.1.0. Copy only the five tested HTML files from my-studio-site into it. Add VERSION.txt containing 0.1.0, CHANGELOG.txt containing v0.1.0 - first practice release, and BUILD.txt containing the Git identifier you copied.
Open PowerShell in release-v0.1.0, run python -m http.server 8001, visit http://localhost:8001, click all five navigation links and narrow the browser window to a phone-like width. Stop with Ctrl+C.
Rollback/reproducibility test: rename the tested release folder to release-v0.1.0-tested. Create a fresh release-v0.1.0 again from the clean Step 12 source, recreate the three text files with the same values, start the local server again and repeat the checks. If the recreated package differs unexpectedly, do not publish it; compare it with the tested copy first.
Success: both practice packages contain the same five site files, version, changelog and build identifier and pass the same local checks. When you later choose a real hosting provider or app store, use that provider's current official publishing instructions.
Turn the idea into evidence.
Compare the tested and recreated release folders file by file. A practice release passes only when the same source checkpoint produces the same intended package contents and checks.
Do not move on until this is true.
You can reproduce the release package from the recorded source revision and explain how you would roll back.
Why we use this principle.
Nyfir Studios treats generated output and verified output as different states. Development work on local AI, Android software and bookkeeping workflows has repeatedly shown that recoverable state, explicit tests and clear product status are more useful than simply producing more output.