Launch prep · QA
Pre-launch QA checklist for kuji services
More important than one successful purchase is confirming that orders and prizes aren't lost in edge cases. Copy the items below into your project QA sheet and record results, owners, and retest dates. When defects are found, release only the scope that has been fixed and retested.
KUJI BUILDER · Last reviewed
1. Check payments, draws, and inventory as one flow
Even if the same payment is resent or several customers request the last item at once, there must be no duplicate draws or overselling. Also check that failed and completed requests are distinguished, so customers see consistent results when they retry.
- Normal approval, decline, customer cancellation, and connection loss after approval
- Repeated identical payment requests or webhooks are processed only once
- Concurrent purchases of the last ticket and no duplicate Last One awards
- Remaining quantities per tier add up to the total remaining
- Orders and results persist after refreshing, going back, and logging in again
2. Customers must be able to get help after purchase
Check that customers can find their order history, shipping status, and support channels on mobile. Submitted consultations or inquiries must be visible to the actual operator, and a success message must never appear when saving fails. Keep operational wording consistent with the reviewed policies.
- Sign-up, login, account recovery, and access permissions
- Combined shipping requests, address changes, and tracking
- Store pickup verification and handling of already-collected prizes
- Inquiry submission, staff review, and reply process
- Required consents, policy links, operator information, and contact details
3. Actually practice recovering from failures
Having backup files doesn't prove they can be restored. Restore to an environment separate from production and check order, inventory, and inquiry records. Also confirm that data persists through server restarts and deployments, and that staff are alerted when health checks fail.
- Access permissions for persistent storage and backups
- Create a backup and verify restoration in a separate environment
- Orders and submission records persist after server restarts and deployments
- Health checks, outage alerts, and the staff contact chain
- Rollback to a known-good version and data handling rules
4. Hand over operating accounts and documents
The person responsible for operations must have access to the domain, payment, cloud, and admin accounts. Clean up test accounts and test orders and keep them separate from real data. Check search visibility after the final domain and public content are confirmed; registering a site doesn't guarantee when it will appear or how it will rank.
- Account owners, billing responsibility, and permission handover
- Changing admin passwords and revoking access for departed staff
- Handing over operating manuals, QA results, and maintenance scope
- Check HTTPS, mobile, 404 pages, and the canonical address on the production domain
- Verify ownership in search services and submit the sitemap