Quick answer: Test your packaged build the way players actually get it: through the itch app, a raw zip, and a browser embed if you have one. Verify save locations, fresh-machine launches, and crash capture, then ship with an in-game report button so your small launch audience can tell you what broke.
itch.io is forgiving in all the wrong ways. There is no certification process, no required testing, and no one stopping you from uploading a build that does not run on a clean machine. That freedom is wonderful until your launch-day players download a zip that crashes on startup and you never hear why. Unlike a console submission that forces you through a checklist, itch trusts you completely, which means the entire burden of catching launch-breaking problems falls on you and the few hours you spend testing before you publish. This checklist covers the QA steps that matter specifically for an itch.io launch and the failure modes that are unique to its distribution model.
Test the build the way players receive it
The build that runs from your IDE is not the build players download. Always test the packaged artifact: download the actual zip from a draft itch page, extract it to a fresh folder, and run it. Path assumptions, missing files, and broken relative references only show up when you run the shipped package, not the editor build.
Players install your game three ways on itch: through the itch desktop app, by downloading a zip directly, and by playing a browser build if you offer one. Each path has its own quirks. Test all three you intend to support, because a build that works in the app can still fail as a raw download.
Browser builds have their own failure modes
HTML5 builds embedded on your itch page run inside an iframe with limited memory, no local file access, and strict audio autoplay rules. Test in multiple browsers and check that audio starts after the first interaction, that the canvas resizes correctly, and that your build does not exceed the memory ceiling on lower-end machines.
Browser builds also cannot write to arbitrary file paths, so any save system that assumes disk access will silently fail. Make sure your web build uses browser storage and that saves persist across a page reload, which players will absolutely do.
Verify save locations on a clean machine
Save-related bugs top the list of itch.io complaints because developers test on the machine where they built the game and never see the fresh-install behavior. Run your packaged build on a clean account or a second machine and confirm that saves are created in the right place, persist across restarts, and survive an update that overwrites the game folder.
A classic itch bug is saving inside the game folder, which gets wiped when the player updates through the itch app. Write saves to the user data directory for the platform so updates never destroy progress.
Ship with crash capture and a report button
Because itch has no crash reporting of its own, you are entirely responsible for knowing when your game dies. Bake in automatic crash capture before launch so unhandled exceptions are recorded with a stack trace and device info and uploaded on the next launch. Without it, a launch-day crash is invisible to you.
Add an in-game report button too. Your itch launch audience is small and motivated, often exactly the players who will give you detailed feedback if you make it easy. Capture a screenshot and device info automatically so a single sentence from a player becomes an actionable report.
Antivirus, permissions, and the first-launch experience
A surprising share of itch.io launch problems have nothing to do with your code. Unsigned executables routinely get flagged by Windows SmartScreen or third-party antivirus, and a player who sees a scary warning on first launch will often just delete the game rather than click through. Test your packaged build on a clean machine with default security settings so you experience exactly what a new player experiences.
macOS adds its own gatekeeping, where unsigned or unnotarized apps are blocked outright with a message that makes it look like the app is broken. Decide before launch how you will guide players past these prompts, whether through a clear note on your itch page or by signing the build, because a first-launch failure produces no crash report and no feedback at all. The player simply leaves, and you never learn why, which is the worst possible outcome for a small launch. Linux builds deserve the same scrutiny: confirm the executable bit survives the zip, that you are not depending on a library that only exists on your development distro, and that the game launches from a file manager double-click and not just your terminal.
A pre-publish QA checklist
Walk this list before you flip the page to public. It is short on purpose, focused on the failure modes that are unique to itch.io distribution.
itch.io launch QA checklist:
[ ] Download and run the actual packaged zip on a clean folder
[ ] Test through the itch desktop app
[ ] Test the browser build in two or more browsers (if offered)
[ ] Confirm audio starts after first interaction in web builds
[ ] Verify saves write to the user data directory, not the game folder
[ ] Confirm saves survive an app update
[ ] Launch on a second machine or clean account
[ ] Automatic crash capture enabled and verified
[ ] In-game report button captures screenshot and device info
[ ] Executable is not flagged by antivirus on a clean machine