Refresh once
If the page is blank or slow, refresh one time before reporting. Do not retry repeatedly if a form is submitting.
BadgerWeb beta status
Check whether production is ready to test.
Use this page when Badger feels slow, blank, or interrupted during internal beta testing. It checks the public production health endpoint and gives testers one clean reporting path.
Live check
Checking Badger production health
Capture the exact page
Include the full URL, device, browser, time, and whether you were logged in.
Use severity clearly
Use blocker for pages that stop testing, confusing for recoverable issues, and visual for layout or design mismatches.
First web internal beta candidate
Share one candidate build with teammate testers.
Use this snapshot for the August 3 handoff so every tester starts from the same production build, route, and feedback format.
Candidate ID: web-beta-candidate-981d9b4
Candidate host: Checking candidate host.
Build source: Vercel production
Deployed at: August 3, 2026 production build
Public landing, beta, support, status, signup, login, confirmation, and recovery pages are included.
Signed-in route to verify: profile setup, Meli, Dear Me, Stories, People, Settings, and sign out.
Feedback must use the support template with host, viewport, URL, severity, expected result, and actual result.
Native mobile is intentionally outside this candidate unless a shared API regression appears.
Beta route check
Checking launch-critical pages.
Production browser QA
Test Vercel production before teammate handoff.
Use this plan for each web beta candidate so launch notes separate production health, browser loading, auth recovery, and signed-in app behavior.
Beta candidate decision note
Copy the launch-readiness result before teammate handoff.
Use this after the production route passes so the team has one reusable candidate, hold, or rerun decision record.
QA host: Checking QA host.
QA viewport: Checking QA viewport.
Public pages load from production without blank screens.
Signup, login, confirmation, and password recovery use one tester email.
Meli, Dear Me, Stories, People, Settings, and sign out pass on one account.
Support reports include host, viewport, URL, severity, expected, and actual.
Only blockers, account recovery, and major UI mismatches remain before freeze.
1. Open production first
Start with badger-ecru.vercel.app. After the custom domain is connected, confirm freelyfeeling.com reaches the same release before sharing it.
2. Check public entry points
Load landing, beta guide, signup, login, support, and status before asking a teammate to create an account.
3. Run one signed-in route
Use one tester email through profile setup, Meli coach, Dear Me journal, Stories, People, Settings, and sign out.
4. Record slow or blank pages
Refresh once, note the URL, device, browser, time, and whether the status checks were healthy before retrying.
5. Freeze only after repeatable pass
A beta candidate is ready when the same production route passes twice without account recovery or routing blockers.
Domain readiness
Confirm which production URL testers are using.
Use this before sharing the beta link. It separates the current Vercel production URL from the custom domain handoff so slow or blank-page reports point to the right host.
Current browser host
Checking current browser host.
Vercel production
badger-ecru.vercel.app
Custom domain
freelyfeeling.com after verification
Use Vercel for first tests
Ask teammates to start on badger-ecru.vercel.app until the custom domain is connected and verified.
Verify custom domain later
freelyfeeling.com is not the tester URL until DNS and the same beta route both pass.
Report the exact host
Every blocker report should include whether the tester used Vercel production, the custom domain, or another URL.
Ready to copy production URLs.
If production is healthy
Continue the same tester route. If the live check passes but a page still fails, report the exact page and action from the support template.