Devlog #8 — QA Sandbox & Production Hardening

CourtQuest is getting closer to the point where I can stop worrying about whether the foundation works and focus on actually building the product.

This week I worked on making testing safer and more realistic by adding an admin-only QA sandbox. Instead of creating random test tournaments in production, admins can now create clearly labeled [QA] tournaments that use the same tournament, bracket, registration, and Google Sheets code paths as real events.

The QA tournaments are private by default, isolated from the normal public tournament listings, and designed to be completely disposable. The teardown process also has multiple safety checks so it refuses to delete anything that isn’t explicitly marked as a QA sandbox tournament.

I also added automated tests covering:

Admin-only access to the QA sandbox
QA tournament creation and deletion
Public/private visibility isolation
Bracket generation
Protection against deleting real tournaments
Database cleanup after teardown
Google Sheets API error handling

The project now has a much stronger CI pipeline as well, with TypeScript checks, linting, unit tests, production builds, and Playwright E2E tests running automatically on pull requests.

One important thing I learned during this process is that passing a local test doesn’t necessarily prove a third-party integration works in production. Google Sheets is a good example: the automated tests can verify the application logic, but the actual organizer-owned Google Sheet flow still needs to be tested against the production OAuth/API environment.

At this point, CourtQuest isn’t “finished” in the sense that there are no more features to build. But the core platform is becoming something I can confidently build on instead of constantly worrying about breaking the foundation.

Next up: finish validating the QA sandbox, run the real production Google Sheets flow, and then get back to shipping actual CourtQuest features.