Launch readiness

What is ready, what still needs review.

This page is the public readiness ledger for UYB. It keeps launch quality, safety boundaries, provider setup, and review needs visible.

Launch decision receiptHold broad launchRelease decision: do not broad launch yet.

The product can keep improving and public smoke can continue, but broad launch should wait until the missing gates have proof.

needs QA email evidenceLive email proof

still requiredLegal sign-off

still requiredHuman phone retest

npm run launch:evidence passesnpm run production:private-evidence passesnpm run production:email-evidence passes

Start carefully Read safety notes

Blocker action room

Only human launch proof remains.

Use this as the owner handoff before broad launch. Each lane names what to do, what proof counts, and what must stay out of notes.

Next owner actionProve live email before launch sign-off.Provider proof still needed

Use this when runtime checks look green so broad launch still waits for live email evidence and human sign-off.

Commandnpm run readiness:check -- --vercel-values --strict --db && npm run production:email-evidenceProof after it

Then complete legal, support, phone, and final sign-off trackers with safe proof only.

1Replace the empty Resend keyProvider ready

Remove the empty production value, add the real Resend key, then rerun strict readiness and live email evidence.

vercel env rm RESEND_API_KEY production && vercel env add RESEND_API_KEY productionreadiness:check reports Email provider key as ok and production:email-evidence sends a QA-only status email

2Get legal and policy sign-offHuman sign-off

Review privacy, terms, cookies, child/guardian consent, notification consent, retention, marketing, and safety pages.

Use the Legal review tracker on this pagelegal review receipt shows named reviewer and pass status only

3Run fresh phone retestsFresh human pass

Ask a real person to repeat the accepted tester fixes on a phone without coaching.

Use the Phone retest tracker and Safe phone pass script on this pagephone review receipt shows pass or fail only and no private notes

one ordered closeoutno secret valuesno private notesbroad launch still held

The blocker action room may show commands, key names, owner lanes, route names, artifact paths, and pass or fail status. It must not store secret values, passwords, OAuth tokens, one-time codes, private journal answers, drafts, reveal text, invite links, another person's writing, support submissions, legal advice, or crisis details.

5D review

Run the 5D launch review.

Use this before broad sharing so UYB is not judged only by build success. Each phase asks whether the product is clear, safe, recoverable, and ready for real people.

DefineWhat problem are we proving for this launch?

A 10-year-old, a teen, a parent, a partner, and an adult can each understand the promise, safety boundary, and first action without extra explanation.

Action: Review the home, how it works, audience pages, guides, and sign-up path on a phone.

DiscoverWhere could a real user feel confused, exposed, or pushed?

Tester feedback, help routes, guide actions, support routing, and safety pages point users toward the right next step without asking for private writing.

Action: Use feedback and support prompts to capture confusion by screen, expected result, actual result, and device.

DesignDoes every screen make the next safe action obvious?

Mobile screens avoid horizontal scroll, overlapping text, hidden save state, unclear invite status, and long hunting between top and bottom actions.

Action: Run the manual phone pass and check the dashboard, journal home, question room, reveal, Solo, Vent Space, Profile, and Help.

DevelopIs the implementation recoverable, private, and provider-ready?

Drafts recover after interruption, provider gates report current status, private routes stay protected, and emails never include journal writing.

Action: Run readiness, database, copy, build, and signed-in QA commands with dedicated QA accounts.

DeliverWhat proof is required before broader sharing?

Live Clerk, Resend, cron, app URL, QA accounts, legal review, support ownership, and two-person phone QA are complete.

Action: Use strict readiness, Vercel production env checks, legal review sign-off, and a real-device two-user launch pass.

npm run readiness:check -- --vercel-values --strict --db

The 5D review can store status, screen names, commands, and safe observations. It must not store private journal answers, drafts, reveal text, invite links, passwords, OAuth tokens, production secrets, or crisis details.

Fix first

Launch blockers still need proof.

The product checks are green, but broad launch still waits for live email proof, legal sign-off, support ownership, and human phone retest.

Final reviewHuman launch proofstill required

Provider gatesReady

Current provider checks are green, but live email evidence still needs a QA-only proof pass.

Product checksReady

The app-side readiness contract is reporting ready.

Proof commandStrict readiness

Run npm run readiness:check -- --vercel-values --strict --db after Vercel values are set.

use dedicated QA accountsdo not test with customer journalskeep secrets out of screenshotsverify on a phone before broad launch

This guide can show key names, status, and commands. It must not show production secret values, passwords, OAuth tokens, journal answers, drafts, or reveal text.

Hold broad launch

Release decision: do not broad launch yet.

The product can keep improving and public smoke can continue, but broad launch should wait until the missing gates have proof.

needs QA email evidenceLive email proof

still requiredLegal sign-off

still requiredHuman phone retest

Safe to continue now

public route smoke checks
copy quality review
mobile visual QA on signed-out pages
legal and consent review
support owner assignment
non-secret Vercel key-name audit

Hold until proof exists

broad public launch until human sign-off
customer-facing announcement until legal and support owners sign off

npm run launch:evidence passesnpm run production:private-evidence passesnpm run production:email-evidence passesnpm run readiness:check -- --vercel-values --strict --db passesdedicated QA owner and guest complete the two-person phone flowlegal, safety, and support owners sign off

Release notes can show routes, commands, owners, pass or fail status, and key names. They must not show production secrets, passwords, OAuth tokens, one-time codes, journal answers, drafts, reveal text, invite links, or customer support details.

Next proof receipt

Next proof: human sign-off.

Provider and product checks look ready from this snapshot. Keep broad launch on hold until live email proof, legal sign-off, support ownership, and a fresh human phone retest are complete.

Final reviewHuman launch sign-offready for reviewnpm run launch:evidenceProof: live email proof, legal sign-off, support ownership, human phone retest, and strict readiness are current

Live email proofReady to prove

Send the QA-only status email and confirm delivery, unsubscribe headers, and private writing exclusion.

npm run production:email-evidenceCounts as proof: production:email-evidence passes with a QA-only status email

Legal sign-offHuman owner needed

Review terms, privacy, cookies, child consent, notification consent, retention, marketing email, and safety language.

Open /legal first, then review /terms, /privacy, /cookies, /notifications, /family-consent, /safety, /accessibility, /newsletter, /unsubscribe, and /launch-readiness

Counts as proof: legal review receipt shows named owner and pass status only

Human phone retestFresh phone pass needed

Ask a real person to repeat the accepted tester fixes on a phone without coaching and record only safe pass or fail notes.

PLAYWRIGHT_BASE_URL=https://understandyoubetter.com npm run visual:mobileCounts as proof: phone review receipt and accepted retest receipt show the tester completed the task without coaching

Strict readiness after fixesReady after human sign-off

Run the final strict audit only after provider values, legal review, support owners, phone retest, and QA accounts are ready.

npm run readiness:check -- --vercel-values --strict --dbCounts as proof: strict readiness passes with Vercel Production values and no private content in notes

do not paste secret valuesdo not capture private writinguse QA-only accountsrecord pass or fail only

Next proof receipts may show key names, commands, route names, safe owner labels, and pass or fail status. They must not show secret values, passwords, OAuth tokens, one-time codes, private journal answers, drafts, reveal text, invite links, support submissions, crisis details, or customer email addresses.

Current as of June 28, 2026

Current proof snapshot.

Use this as the quick read before anyone asks whether UYB is ready. It separates evidence that already exists from proof that still needs a provider, counsel, or real human retest.

Public mobilePassed

Forty public routes passed on the canonical production domain with no failed routes, no horizontal overflow, and the Newsletter topic fit guide visible on Newsletter, including Topic fit, Pick by what you want help with, I want better words, topic choice only, no private story, and unsubscribe stays available.

test-results/mobile-visual-qa-newsletter-topic-fit-production/manifest.json

Human validation trackerReady to use

Launch Readiness now includes a local pass-status tracker for the Younger user, Adult creator, Invited person, and Returning user scripts, plus a Human validation receipt.

test-results/mobile-visual-qa-real-user-validation-tracker-production/manifest.json

AccessibilityPassed

Twenty-seven public routes passed named-control, landmark, heading, contrast, reduced-motion, and tap-target checks after the FAQ center update, including Frequently asked questions without private stories, FAQ review receipt, private writing stays out, no open comments, and not therapy or legal advice.

test-results/public-accessibility-evidence-faq-center-production/manifest.json

Signed-in mobilePassed

Eight protected routes passed with the QA owner at 393px on the canonical production domain after the Solo and Vent in-flow shortcut update, including Writing shortcuts, Vent shortcuts, one tap on phone, safety stays visible, no product-facing sticky phone contract, no horizontal overflow, named mobile controls, and no first-viewport obstruction.

test-results/signed-in-mobile-visual-qa-solo-vent-in-flow-production/manifest.json

Two-person flowPassed

The writing compose rail production pass proves QA cleanup, owner and guest sign-in, invite, join, the Compose rail before the answer box on both writing sides, Jump to answer box, prompt stays visible, starter is editable, draft backup visible, no one is notified, reveal, private reflection, return, second journal creation, signed-in visual QA, and final cleanup.

test-results/production-private-evidence-writing-compose-rail/manifest.json

Interruption safetyPassed

Seven source-backed flows passed fresh current-goal interruption evidence for journal answers, reflections, setup, profile edits, Solo, Vent, and offline reassurance.

test-results/interruption-safety-evidence-current-goal-continuation/manifest.json

Email contractPassed

Current provider-free email proof verifies status-only content, unsubscribe headers, private-text exclusion, safe links, and created-journal reminder copy. Live delivery still needs Resend.

test-results/production-email-contract/manifest.json

Database evidencePassed

Clean database evidence commands now strip managed SSL parameters before creating pg clients, so db:check, db:migrate, and production:email-contract run without noisy duplicate SSL warnings.

scripts/pg-client-config.mjs

Tester closurePassed

Four accepted tester feedback packets are mapped to product behavior and production evidence in the fresh current-goal continuation pass, while fresh human retest remains required.

test-results/tester-feedback-closure-current-goal-continuation/manifest.json

Resend key

Email delivery still needs a non-empty production provider key and email evidence.

Legal review

Privacy, terms, cookies, child consent, notification, retention, and marketing still need human sign-off.

Human retest

The four accepted tester fixes still need fresh human retest notes from real phones.

PLAYWRIGHT_BASE_URL=https://understandyoubetter.com UYB_VISUAL_QA_DIR=test-results/mobile-visual-qa-newsletter-topic-fit-production npm run visual:mobile

PLAYWRIGHT_BASE_URL=https://understandyoubetter.com UYB_ACCESSIBILITY_EVIDENCE_DIR=test-results/public-accessibility-evidence-faq-center-production npm run accessibility:evidence

UYB_RUN_AUTH_E2E=1 PLAYWRIGHT_BASE_URL=https://understandyoubetter.com UYB_SIGNED_IN_VISUAL_QA_DIR=test-results/signed-in-mobile-visual-qa-solo-vent-in-flow-production npm run visual:mobile:signed-in -- --vercel-production

PLAYWRIGHT_BASE_URL=https://understandyoubetter.com UYB_PRIVATE_EVIDENCE_DIR=test-results/production-private-evidence-writing-compose-rail UYB_SIGNED_IN_VISUAL_QA_DIR=test-results/signed-in-mobile-visual-qa-writing-compose-rail-private-evidence npm run production:private-evidence

UYB_INTERRUPTION_EVIDENCE_DIR=test-results/interruption-safety-evidence-current-goal-continuation npm run interruption:evidence

UYB_EMAIL_EVIDENCE_DIR=test-results/production-email-contract npm run production:email-contractnpm run db:check && npm run db:migrateUYB_TESTER_FEEDBACK_CLOSURE_DIR=test-results/tester-feedback-closure-current-goal-continuation npm run tester:closure

Proof snapshots can name commands, routes, artifacts, pass or fail status, and safe QA labels. They must not include journal answers, drafts, reveal text, invite links, customer emails, screenshots with private writing, passwords, OAuth tokens, production secrets, or crisis details.

Human proof hold

Do not broad launch until these human proofs exist.

This hold summary keeps the non-code work in one place so green tests cannot be mistaken for broad launch approval.

ready to proveLive email proof

Send the QA-only status email, prove unsubscribe, and confirm private writing stays out.

Proof: production:email-evidence passes

human approval neededLegal sign-off

Privacy, terms, cookies, family consent, notification consent, retention, marketing, and safety claims need formal review.

Proof: legal tracker has approved marks plus external counsel packet

owner names neededSupport ownership

Account, privacy, safety, tester, and product-feedback routes need named owners and escalation expectations.

Proof: support owner receipt has ready marks and external inbox coverage

fresh tester pass neededHuman phone retest

A real younger user, adult creator, invited person, and returning user should complete the scripts without coaching.

Proof: real user, phone review, and accepted-fix retest trackers show pass status only

3 human proof lanes still not launch-approvedprovider green is not approvallocal trackers are coordination onlysafe pass status only

Human proof hold notes may include lane names, owner roles, route names, pass or fail status, and artifact paths. They must not include private journal answers, drafts, reveal text, invite links, screenshots with private writing, customer contact details, legal advice, crisis details, passwords, OAuth tokens, one-time codes, or production secrets.

Launch owner runway

Use this order, but keep launch on hold.

The code-facing gates may look ready, but the launch owner still needs live email proof, phone retest, owner sign-off, and final evidence in order.

9/9 provider gates3 lanes human reviewhold until sign-off proof state

First
Provider checks are green, not launch approval.Provider checks only
This means the configured services can move into proof. Broad launch still waits for email evidence, legal review, support ownership, and phone retest.
npm run readiness:check -- --vercel-values --strict --dbProof: Run strict readiness, live email evidence, and the human owner trackers.
Second
Run the human phone pass.Human retest
Use the accepted tester scripts and real-device tracker so a fresh person can prove the original confusion is resolved without coaching.
PLAYWRIGHT_BASE_URL=https://understandyoubetter.com npm run visual:mobileProof: Phone review receipt and Safe retest receipt show pass status only.
Third
Assign legal and support owners.Human owners
Record reviewer or team names for legal, privacy, child consent, safety, account, and tester-report routes. Keep private writing out of notes.
Open /launch-readiness and complete the local owner trackersProof: Legal review receipt and Support owner receipt have local ready marks.
Last
Refresh the launch proof packet.Only after sign-off
Run the full evidence packet after provider setup, human phone pass, support ownership, legal review, and live email proof are complete.
npm run launch:evidenceProof: Public mobile, accessibility, signed-in, private flow, interruption, email, and tester closure manifests are current.

one ordered pathno secret valuesno private writinghuman sign-off stays separate

The launch owner runway may show key names, route names, commands, pass or fail status, owner lanes, and safe artifact names. It must not store production secrets, OAuth tokens, passwords, one-time codes, private journal answers, drafts, reveal text, invite links, support submissions, or crisis details.

Production setup

Production setup still needs these values.

These are operations gates, not product copy. They keep launch testing honest before UYB is broadly shared.

RequiredClerk production

NEXT_PUBLIC_CLERK_PUBLISHABLE_KEYCLERK_SECRET_KEY

Use live Clerk keys for the production instance. Test keys are useful for development, but they keep the launch gate incomplete.

Run npm run readiness:check -- --vercel-values and confirm both Clerk checks say live.

RequiredCanonical app URL

UYB_APP_URL

Set the production app URL so email links, cron jobs, and canonical references agree on the same home.

Expected value: https://understandyoubetter.com

RequiredNotification cron

CRON_SECRET

Use a long random secret for scheduled notification routes so only the trusted cron caller can trigger sends.

Run npm run readiness:check -- --vercel-values and confirm Notification cron secret says configured.

RequiredResend email

RESEND_API_KEYUYB_EMAIL_FROM

Connect the email provider and a verified sender before reminder or newsletter email is treated as live.

Send a profile test update and confirm no email contains private journal writing.

RequiredClerk QA users

UYB_QA_OWNER_EMAILUYB_QA_OWNER_USER_ID or UYB_QA_OWNER_PASSWORDUYB_QA_GUEST_EMAILUYB_QA_GUEST_USER_ID or UYB_QA_GUEST_PASSWORD

Create two production QA accounts so the real two-person flow can be tested without using private customer accounts.

Run the authenticated two-user QA flow after the env values are set.

Do not paste secrets into feedback, chat, screenshots, or public pages.

Current status

What this environment reports right now.

This snapshot mirrors the readiness command without showing any secret values. It separates product infrastructure that is already present from provider gates that still need setup.

32 passing0 incomplete

Product checks

ok
Database URLconfigured
ok
Mobile service worker filecovered by release evidence
ok
Offline fallback pagecovered by release evidence
ok
Service worker registrationcovered by release evidence
ok
Private routes excluded from offline cachecovered by release evidence
ok
Public sitemap policycovered by release evidence
ok
AI discovery boundarycovered by release evidence
ok
Public metadata helpercovered by release evidence
ok
Public JSON-LD componentcovered by release evidence
ok
Public mobile accessibility smokecovered by release evidence
ok
Real app start CTA contractcovered by release evidence
ok
Legal and trust surfacescovered by release evidence
ok
Premium private experience surfacescovered by release evidence
ok
Premium database schema contractcovered by release evidence
ok
Premium mobile interface contractcovered by release evidence
ok
Signed-in mobile visual QA contractcovered by release evidence
ok
Mobile install and offline app shell contractcovered by release evidence
ok
Copy quality contractcovered by release evidence
ok
Notification and marketing delivery contractcovered by release evidence
ok
Age-aware safety and consent contractcovered by release evidence
ok
Safe curated question system contractcovered by release evidence
ok
Interruption-safe writing persistence contractcovered by release evidence
ok
Help, support, and recovery contractcovered by release evidence

Provider gates

ok
Clerk public keyconfigured
ok
Clerk secret keyconfigured
ok
Clerk key pairconfigured
ok
Canonical app URLconfigured
ok
Notification cron secretconfigured
ok
Email provider keyconfigured
ok
Email senderconfigured
ok
Clerk QA ownerconfigured
ok
Clerk QA guestconfigured

This public snapshot shows provider status and release-evidence product contracts only. The CLI readiness command remains the source-file audit and never prints secret values, account emails, API keys, or private journal content.

Next actions

Provider gates are ready.

The current provider snapshot does not report missing provider gates.

Provider gates are green.Run the two-person QA flow before broad launch.

Paste secret values only into Vercel or ignored local env files. Public pages, screenshots, chat, docs, and support tickets should show key names only.

Provider ready

Email delivery handoff is ready for final proof.

Provider setup looks ready. Send the QA-only email evidence before treating reminders or newsletters as live.

okResend keyconfigured

okSenderconfigured

okCronconfigured

Replace
Replace the empty provider keyvercel env rm RESEND_API_KEY production && vercel env add RESEND_API_KEY production
Use the production Resend key from the verified UYB sender account. Paste it only into Vercel or an ignored local env file.
Sender
Confirm the verified sendervercel env add UYB_EMAIL_FROM production
Use a verified sender on the UYB domain so reminders and newsletters come from a recognizable place.
Audit
Run strict production readinessnpm run readiness:check -- --vercel-values --strict --db
The command should pass with Email provider key ok, sender configured, app URL configured, cron secret configured, and the database schema ready.
Proof
Send the QA-only email evidencenpm run production:email-evidence
The proof should show a QA-only status email was sent, unsubscribe works, and no journal answer, draft, reveal, solo, or vent text entered the message.

QA-only status email sentunsubscribe worksprivate writing excludedprovider values never shown

Email handoff proof may store key names, pass or fail status, provider labels, and QA-only message evidence. It must not store Resend key values, OAuth tokens, one-time codes, passwords, private journal answers, drafts, reveal text, solo notes, vent text, invite links, support submissions, or crisis details.

Ready for live proof

Run the live email proof without exposing secrets.

The provider checks look ready. Send one QA-only status email, confirm unsubscribe behavior, and keep private journal writing out of the evidence.

okRESEND_API_KEYconfigured

okUYB_EMAIL_FROMconfigured

okCRON_SECRETconfigured

1
Run strict readinessnpm run readiness:check -- --vercel-values --strict --db
Confirm the production values are shaped correctly without printing secret values.
2
Send QA-only email evidenceUYB_EMAIL_EVIDENCE_DIR=test-results/production-email-evidence-resend-live npm run production:email-evidence
Use a QA account and status-only message proof. Do not use a customer journal.
3
Read the delivered messagemanual inbox review
Confirm the email says only safe status, unsubscribe works, and no answer, draft, reveal, invite link, solo note, or vent text appears.

Proof to keep

non-empty Resend key
verified sender
strict readiness green
QA-only email evidence
private writing excluded

Broad launch still held by

legal sign-off
real phone retest
support owner confirmation
final broad launch approval

Only paste secret values into Vercel or ignored local env files. Resend closeout evidence may name key labels, commands, pass status, QA-only message status, and unsubscribe status. It must not include API keys, OAuth tokens, passwords, one-time codes, private journal answers, drafts, reveal text, solo notes, vent text, invite links, support submissions, or crisis details.

Mobile QA

Mobile QA can start with real accounts.

The core auth, database, app URL, and QA account gates are reporting ready. Use dedicated QA accounts, then smoke the full two-person flow on a phone.

Primary blockerNone

AuthUse one Clerk environment

Ready

The public key and secret key must both come from the same live Clerk instance.

Evidence: readiness:check shows Clerk public key, Clerk secret key, and Clerk key pair as ok.

QA usersUse dedicated test people

Ready

Create owner and guest QA accounts so no customer, founder, or tester journal is used for launch checks.

Evidence: readiness:check shows Clerk QA owner and Clerk QA guest as ok.

Phone passSmoke the full signed-in path

Ready

Create a journal, write both sides, open the reveal, save a reflection, and confirm Today, Updates, and Journeys agree.

Evidence: Authenticated QA flow passes on a real phone or mobile browser viewport.

Visual passCapture signed-in mobile surfaces

Ready

Run the signed-in visual QA command with the dedicated QA owner after cleanup. It checks dashboard, profile, journeys, updates, setup, solo, and vent without customer data.

Evidence: test-results/signed-in-mobile-visual-qa-solo-vent-in-flow-production/manifest.json shows the signed-in routes pass with Solo and Vent in-flow shortcuts and no horizontal overflow.

Do not use private customer content for QA. Do not paste keys, account secrets, journal answers, screenshots with private writing, or OAuth credentials into public docs or chat.

Phone pass

Manual mobile review before broad launch.

Use this phone pass after automated checks. It focuses on the moments where a real user could lose trust, context, or writing. Capture public screenshots with the visual QA command, then do signed-in checks only with QA accounts.

PLAYWRIGHT_BASE_URL=https://understandyoubetter.com UYB_VISUAL_QA_DIR=test-results/mobile-visual-qa-newsletter-topic-fit-production npm run visual:mobile

Public proof command

PLAYWRIGHT_BASE_URL=https://understandyoubetter.com UYB_VISUAL_QA_DIR=test-results/mobile-visual-qa-newsletter-topic-fit-production npm run visual:mobile

test-results/mobile-visual-qa-newsletter-topic-fit-production/manifest.json

Signed-in proof command

UYB_RUN_AUTH_E2E=1 PLAYWRIGHT_BASE_URL=https://understandyoubetter.com UYB_SIGNED_IN_VISUAL_QA_DIR=test-results/signed-in-mobile-visual-qa-solo-vent-in-flow-production npm run visual:mobile:signed-in -- --vercel-production

test-results/signed-in-mobile-visual-qa-solo-vent-in-flow-production/manifest.json

First viewportThe next action is visible without hunting.

/, /dashboard, /pair/new, /kids, /parents

H1, primary action, safety or privacy boundary, and navigation fit without overlap on a phone viewport.

Writing recoveryA call, refresh, or app switch does not erase trust.

/pair/[inviteCode]/question/[sessionId], /solo, /vent

Device draft, account draft, save confidence, and final save states stay understandable after reload or return.

Two-person statusUsers can tell what the other person can and cannot see.

/pair/[inviteCode], /pair/[inviteCode]/question/[sessionId], /updates

Draft, saved, waiting, reveal, invite, and reflection states never expose private text.

Young user safetyKids and adults both understand the consent boundary.

/kids, /parents, /safety, /profile

Trusted grown-up, no hidden monitoring, no forced confession, and real-world safety help are visible.

Reduced motionPremium polish does not depend on motion.

/, /dashboard, /question-studio, /games/word-rooms

Reduced-motion settings keep the interface stable, readable, and usable without animated state changes.

Public entryBrand, first action, and product boundary are clear in the first phone viewport.

//start-here/how-it-works/features

No hero text overlap, no horizontal scroll, primary CTA visible, and the next section peeks into view.

Signed-in homeThe app shell feels consistent and the next action is easy to scan.

/dashboard/journeys/updates/profile

Bottom navigation, Today status, profile controls, and journey filters do not collide or hide save state.

Writing roomsWriting surfaces stay calm, stable, and private.

/pair/[inviteCode]/pair/[inviteCode]/question/[sessionId]/solo/vent

Textarea, save state, draft recovery, reveal status, and support rail stay visible without page hunting.

Trust and helpPeople can find a safe next step without sharing private writing.

/help/faq/support/privacy/cookies/safety/accessibility

Boundary copy, support routes, legal notes, and accessibility reports fit with readable contrast.

Family audienceA younger person and an adult can both understand consent and safety.

/kids/teens/parents/family-consent/adults

No hidden monitoring language, no therapy claims, and age-aware CTAs remain clear on a phone.

Interactive toolsTools feel playable and useful without becoming a feed or advice system.

/question-studio/questions/games/games/word-rooms

Controls keep 44px targets, reduced motion works, and question previews do not ask for private answers.

Younger userKid or young teen with a trusted adult nearby

Start at /start-here, choose the safest path, open the kids or teens guide, then explain what stays private.

Pass signal: They can say they do not have to share private writing and they know to pause or ask a trusted adult.
Safe notes: Record route names, unclear words, tap trouble, and whether the trusted-adult boundary made sense.

Adult creatorAdult starting a journal

Create a journal from /pair/new, write one private side when ready, and decide whether to share the invite.

Pass signal: They understand they can write first, UYB does not send the invite, and reveal waits for both people.
Safe notes: Record setup confusion, save confidence, invite clarity, and whether the next action was visible on phone.

Invited personSecond person joining from a private invite

Open a QA invite, join with the right side label, answer privately, and describe when the reveal opens.

Pass signal: They understand joining does not reveal writing and both people save before anything opens.
Safe notes: Record join clarity, side-label fit, waiting-state clarity, and any point where they felt watched or rushed.

Returning userSomeone returning after an interruption

Start a draft in a shared room or Private Write, reload or switch away, return, and choose the next safe action.

Pass signal: They can find their draft or saved state, understand what stayed private, and continue without coaching.
Safe notes: Record recovery clarity, scroll friction, visible save state, and whether the quick path reduced hunting.

tester completed the task without coachingtester named what stayed privatetester found the next safe actiontester knew how to pause or return

Real user validation tracker0 of 4 scripts passed

Human validation still needs safe pass marks.

tester completed the task without coachingtester named what stayed privatetester found the next safe actiontester knew how to pause or return

Younger userKid or young teen with a trusted adult nearby

Start at /start-here, choose the safest path, open the kids or teens guide, then explain what stays private.

They can say they do not have to share private writing and they know to pause or ask a trusted adult.

Status

Adult creatorAdult starting a journal

Create a journal from /pair/new, write one private side when ready, and decide whether to share the invite.

They understand they can write first, UYB does not send the invite, and reveal waits for both people.

Status

Invited personSecond person joining from a private invite

Open a QA invite, join with the right side label, answer privately, and describe when the reveal opens.

They understand joining does not reveal writing and both people save before anything opens.

Status

Returning userSomeone returning after an interruption

Start a draft in a shared room or Private Write, reload or switch away, return, and choose the next safe action.

They can find their draft or saved state, understand what stayed private, and continue without coaching.

Status

This is launch evidence, not a substitute for legal review, provider setup, signed-in two-user QA, or real safety support. The real-device tracker stores device labels and pass status only. Screenshot artifacts must not include private journal answers, drafts, reveal text, invite links, account details, account secrets, production secrets, support submissions, or crisis details.

Human validation receiptReal user validation still needs pass marks.

Run each script without coaching. The tester should name the next safe action and what stayed private.

0 passed0 testing4 waitinglocal device onlyno private notes

Younger user
Adult creator
Invited person
Returning user

This tracker stores script labels and pass status only on this device. It does not store private notes, journal answers, draft text, invite links, account details, child identity details, production secrets, or crisis details. It does not prove legal approval, provider setup, support coverage, child consent, or broad launch readiness.

no horizontal scrollno overlapping text44px tap targetsprivate text stays privateone clear next actionglass surfaces stay readablereduced motion still feels complete

Real-device review tracker0 of 6 phone checks passed

Real-device proof is still being gathered.

Safe phone pass scriptRun the task without coaching, then record pass or fail only.

Ask the tester to use the phone naturally. They should name the next safe action, what stayed private, and how they would pause or return.

tester completed the task without coachingtester named what stayed privatetester found the next safe actiontester knew how to pause or return

Keep real notes outside UYB launch pages. Do not store private answers, draft text, invite links, account details, screenshots with private writing, or crisis details here.

Public first viewThe first screen says what UYB is, gives one obvious next step, and never needs sideways scrolling./, /start-here, /helpiPhone Safari or Android Chrome

DeviceStatus

Signed-in returnA returning user can see what is waiting, what is private, and where to go next without reading launch-owner copy./dashboard, /profile, /journeys, /updatesiPhone Safari

DeviceStatus

Private writingThe writing box stays visible while typing, autosave or draft recovery is clear, and a phone call or reload does not erase the path./solo, /vent, /pair/newAndroid Chrome

DeviceStatus

Two-person statusThe owner and guest can tell who has joined, who still needs to write, when reveal opens, and how to come back later./pair/[inviteCode]Two real phones

DeviceStatus

Younger-user careThe copy feels kind and clear, explains pause and trusted-adult options, and does not pressure a confession./kids, /teens, /safety, /family-consentSmall phone viewport

DeviceStatus

Motion and accessControls remain tappable, transitions stay calm, support is findable, and status messages are understandable without private details./accessibility, /support, /notificationsReduced motion and large text

DeviceStatus

Phone review receiptReal-device review still needs phone passes.

6 real-device checks still need a phone pass before broad launch. Store device names and pass status only.

0 passed0 testing6 waitinglocal device onlyno private writing

Public first view
Signed-in return
Private writing
Two-person status
Younger-user care
Motion and access

This receipt is local coordination only. It stores device labels and pass status only. It does not prove legal approval, provider setup, email delivery, support coverage, crisis response, or broad launch readiness.

Retest fixes

Retest the fixes that used to confuse people.

These checks turn the original tester confusion into simple mobile tasks. A pass means the tester can explain the screen without founder help.

Shared inviteSign in after someone shares a UYB link, then find where to paste or open the shared journal.

/dashboard

Tester can find the invite path, knows no answer opened, and knows the next step is a shared question.

Before questionCreate a journal and stop on the journal home before the other person joins.

/pair/[inviteCode]

Tester understands that the invite link comes first and the question appears after the journal is ready.

Write firstStart the first guided question and save your side before the other person answers.

/pair/[inviteCode]/question/new

Tester knows their writing is private, the reveal is locked, and waiting does not mean they did anything wrong.

Phone interruptionType a short safe placeholder, leave or reload the page, then return to the same writing room.

/pair/[inviteCode]/question/[sessionId]

Tester can see the restored draft or saved state and does not have to scroll around to understand the next action.

Pass signals

tester found the right screen
tester named the next action
tester understood what stayed private
tester could pause without pressure

Never collect

real journal answers
draft text
invite links
reveal text
names of the other person
screenshots with private writing

Phone retest tracker0 of 4 checks passed

Retest proof is still waiting on at least one phone pass.

Shared inviteTester can find the invite path, knows no answer opened, and knows the next step is a shared question.Before questionTester understands that the invite link comes first and the question appears after the journal is ready.Write firstTester knows their writing is private, the reveal is locked, and waiting does not mean they did anything wrong.Phone interruptionTester can see the restored draft or saved state and does not have to scroll around to understand the next action.

local to this browsercheckboxes onlyno private notessafe pass signals

This local tracker records only whether each accepted fix passed on this device. It does not store tester notes, private writing, invite links, screenshots, account details, or customer secrets.

Safe retest receiptThis device still needs a human phone pass before the accepted fixes count as closed.

record tester role, device, browser, route, and pass or failuse fixture text only when a screenshot is neededfile remaining confusion through product feedbackkeep journal answers and invite links out of evidence

Shared invite
Before question
Write first
Phone interruption

This receipt is local status only. It should never include private writing, reveal text, invite links, account secrets, screenshots with private text, or crisis details.

Send safe retest notes Back to readiness

A retest note should describe product clarity only. It should not store private writing, invite links, real relationship details, screenshots with private text, or customer account secrets.

Performance

Mobile performance is part of trust.

UYB should feel quick enough that users do not wonder if their private writing disappeared. These budgets focus on clarity, stability, recovery, and provider honesty.

npm run test:e2e:public -- --project=mobile-chromium

First viewportLoads clearly before the user scrolls

H1, primary action, trust boundary, and nav fit on a 390px phone without overlap.

Evidence: Public mobile smoke checks the H1, no horizontal overflow, first-viewport obstruction, contrast samples, tap targets, and footer trust links.

Writing stabilityNo lost writing during interruption

Draft recovery, save status, and textarea position stay stable after reload, call, or app switch.

Evidence: Journal and solo tests cover account drafts, device drafts, submitted cleanup, and save confidence.

Motion costMotion never blocks the task

Reduced-motion mode forces animation, transition, and scroll behavior down to calm values.

Evidence: Public mobile smoke checks reduced-motion runtime behavior.

Provider latencyExternal services cannot hide status

Auth, email, and cron failures show provider status without exposing private content or secrets.

Evidence: Readiness and notification tests require redacted provider failures.

Offline returnThe app recovers when connection changes

Offline shell avoids private route caching, local drafts stay device-only, and network status is visible.

Evidence: Service worker, offline fallback, and network banner contracts are checked in readiness.

no first-viewport overlapno horizontal scrolltextarea stays visible while writingdraft recovery is obviousreduced motion still worksprovider delays show safe status

Performance notes can include route names, timing observations, screenshots without private text, and pass or fail status. They must not include journal answers, drafts, reveal text, invite links, account secrets, production secrets, or support submissions.

Gap analysis

Premium gap analysis.

This keeps the product honest. A feature only counts as premium when there is proof that a real user can understand it, trust it, return to it, and use it on a phone.

promiseevidencemissing proofnext check

First-run guidanceA new user knows the safest next step without founder coaching.

Evidence: Start Here, guided sign-up context, dashboard setup, profile care agreement, and journal creation paths are wired.
Missing proof: A real phone pass with one younger tester, one adult tester, and one invited partner has not been recorded.
Next check: Watch each tester reach their first saved answer without explaining the product.

Private return loopUsers can come back after a call, reload, or hard day without losing writing or context.

Evidence: Account drafts, device drafts, journeys, updates, saved reflections, solo entries, archive or restore, live Clerk keys, and dedicated QA users are present.
Missing proof: Fresh production private evidence must be repeated after any auth, journal, database, or app-shell change.
Next check: Run the live two-user journey from create to reveal to return history with cleanup before and after.

Personal expressionThe app feels personal without becoming public, performative, or searchable.

Evidence: Profile avatars, themes, stickers, journal icons, pinned journals, and private guide preferences exist.
Missing proof: Manual visual QA needs to confirm personalization is readable, inclusive, and not visually noisy on small screens.
Next check: Review dashboard, profile, journal home, and journeys with three theme and avatar combinations.

Safe communicationUYB helps people say hard things without turning into chat, public posting, or advice threads.

Evidence: Paired reveals, solo space, vent space, curated questions, reflection prompts, and no public feeds are enforced.
Missing proof: Safety language still needs legal and child/family review before broad public launch.
Next check: Review safety, terms, privacy, kids, teens, parents, family consent, vent, and reveal screens together.

Growth and discoveryPeople and AI assistants can understand UYB without seeing private journals.

Evidence: Public guides, blog article next steps, Q&A, sitemap, robots, llms.txt, metadata, newsletter opt-in, canonical-domain visual QA, and analytics boundaries are present.
Missing proof: Search Console style review, final snippet review, and the external Resend provider gate still need final proof before broad launch.
Next check: Review generated snippets on the canonical domain, confirm no private-content leakage, and rerun readiness after the Resend key is real.

first answer saved without coachingreturn loop works after interruptionpersonalization stays privatesafety copy passes reviewpublic discovery excludes private content

Gap notes may include route names, tester role, device type, safe observations, commands, and pass or fail status. They must not include private journal answers, draft text, invite links, account secrets, production secrets, crisis details, or private support submissions.

Personalization

Personal expression review.

Personalization only counts as premium if it helps people recognize their own side without making the app loud, public, or hard to read on a phone.

UYB_RUN_AUTH_E2E=1 PLAYWRIGHT_BASE_URL=https://understandyoubetter.com npm run visual:mobile:signed-in -- --vercel-production

Younger userSoft avatar, gentle theme, kid-safe support mode

/profile

A younger reader can tell the profile is private and can still find Today without coaching.

Adult userClear avatar, calm theme, adult support mode

/dashboard

An adult can scan the private identity chip, next step, and journal status without visual noise.

Shared journalTwo side labels, custom journal icon, pinned journal

/journeys?journal=archived

The combination helps recognition while keeping profile choices hidden from the other person.

Notification viewPrivate label, glass card, update receipt

/updates

Badges, proof chips, and bottom navigation stay readable on a small phone.

Local personalization review tracker0 of 4 combinations passed

Personalization proof still needs small-screen passes.

small-screen readableidentity stays privateno visual noiseinclusive labelssafe to change

Next safe reviewYounger user

A younger reader can tell the profile is private and can still find Today without coaching.

/profileSoft avatar, gentle theme, kid-safe support mode

Allowed evidence

route name
device size
combination label
pass or fail status

Never record here

private profile details
journal answers
invite links
account details

Younger userSoft avatar, gentle theme, kid-safe support mode/profileA younger reader can tell the profile is private and can still find Today without coaching.

Status

Adult userClear avatar, calm theme, adult support mode/dashboardAn adult can scan the private identity chip, next step, and journal status without visual noise.

Status

Shared journalTwo side labels, custom journal icon, pinned journal/journeys?journal=archivedThe combination helps recognition while keeping profile choices hidden from the other person.

Status

Notification viewPrivate label, glass card, update receipt/updatesBadges, proof chips, and bottom navigation stay readable on a small phone.

Status

This review stores combination labels and pass status only on this device. It must not include private profile details, journal answers, draft text, invite links, account details, screenshots with private writing, child identity details, or production secrets.

Personalization review receiptPersonal expression still needs local pass marks before broad launch.

0 passed0 reviewing4 waitinglocal device onlyno private profile details

Younger user
Adult user
Shared journal
Notification view

This receipt is local coordination only. It does not prove legal approval, child consent, broad launch readiness, live support coverage, provider setup, or a public profile review.

Commands

Add the missing env values without exposing secrets.

Run each command from the linked Vercel project. Paste values only into Vercel or ignored local env files, then audit key presence before strict value-shape checks.

Canonical URLvercel env add UYB_APP_URL production

Value shape: https://understandyoubetter.comProof: readiness:check shows Canonical app URL ok.

Clerk public keyvercel env add NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY production

Value shape: Starts with pk_liveProof: readiness:check shows Clerk public key ok.

Clerk secret keyvercel env add CLERK_SECRET_KEY production

Value shape: Starts with sk_liveProof: readiness:check shows Clerk secret key ok.

Resend API keyvercel env rm RESEND_API_KEY production && vercel env add RESEND_API_KEY production

Value shape: Non-empty production Resend key from the verified accountProof: readiness:check -- --vercel-values shows Email provider key ok.

Email sendervercel env add UYB_EMAIL_FROM production

Value shape: Verified sender on the UYB domainProof: Reminder email uses the verified From address.

Cron secretvercel env add CRON_SECRET production

Value shape: Long random value stored only in VercelProof: readiness:check shows Notification cron secret ok.

QA owner accountvercel env add UYB_QA_OWNER_EMAIL production && vercel env add UYB_QA_OWNER_USER_ID production

Value shape: Dedicated production QA owner email plus user ID or passwordProof: Authenticated owner flow can create a journal.

QA guest accountvercel env add UYB_QA_GUEST_EMAIL production && vercel env add UYB_QA_GUEST_USER_ID production

Value shape: Dedicated production QA guest email plus user ID or passwordProof: Authenticated guest flow can join and write.

npm run readiness:check -- --vercel-valuesnpm run readiness:check -- --vercel-values --strict --dbvercel --prod --yes

Do not paste production secrets into chat, feedback, screenshots, docs, git, or public support tickets.

Handoff

Exact order to finish production setup.

This is the safe handoff sequence for moving from a working product build to a production-ready launch gate.

1
Add production env valuesvercel env add KEY production
Add each missing production value in Vercel. Paste the value only into Vercel, never into chat, feedback, screenshots, or docs.
Evidence: Each required key exists in the Production environment.
2
Audit Vercel production keysnpm run readiness:check -- --vercel-values
Validate Vercel Production values from a temporary ignored file without printing or committing secret values.
Evidence: The audit shows live Clerk keys, configured cron and app URL, and flags empty or missing provider values.
3
Run strict readinessnpm run readiness:check -- --vercel-values --strict --db
Use strict mode with pulled Vercel Production values when you need value-shape checks for live Clerk keys, Resend, app URL, cron secret, QA users, and the current database schema.
Evidence: The command exits 0, every readiness line says ok, and the database audit reports all required premium columns.
4
Collect release evidencenpm run launch:evidence
Run the release evidence pack before deploy so tester packets, copy, interruption safety, trust tests, public mobile smoke, public visual screenshots, pulled Vercel Production readiness, database schema, and build are checked together.
Evidence: The command exits 0, prints that the UYB launch evidence check passed, and writes manifests such as test-results/mobile-visual-qa/manifest.json and test-results/signed-in-mobile-visual-qa/manifest.json when the public and signed-in visual passes run.
5
Run the two-person QA flownpm run production:private-evidence
Use dedicated production QA accounts to prove signed-in mobile surfaces, profile setup, invite, guest join, draft recovery, reveal, reflection, updates, second journal creation, and cleanup.
Evidence: The command exits 0 on the canonical domain, writes the signed-in visual manifest, and final qa:cleanup reports no QA-only journals left afterward.
6
Deploy after gates passvercel --prod --yes
Deploy only after the provider gates and QA flow are green. Then smoke the public site on mobile and desktop.
Evidence: Vercel inspect shows Ready and the canonical domain serves the latest build.

Do not share secret values in screenshots. Show only key names and pass or fail status. Pull production env locally only into ignored files when value-shape validation is required.

Sign-off

Do not launch until each sign-off has proof.

This separates local checks from production provider setup, live QA, legal review, support ownership, and deployment inspection. A green build alone is not enough.

Release evidencenpm run launch:evidence passes on the release branch and writes the public mobile visual manifest.

Product and engineering

Ready to run with Vercel CLI access

Provider envVercel Production values pass strict readiness with live Clerk keys, app URL, Resend, cron secret, and QA accounts, then npm run production:email-evidence marks a QA-only status email sent.

Operations

Blocked until production values are configured

Live two-user QADedicated QA owner and guest complete create, invite, write, wait, reveal, reflect, and return on the canonical production domain.

Launch QA owner

Verified on production with dedicated QA accounts; repeat after major auth, journal, or database changes

Legal and safety reviewPrivacy, terms, cookies, notifications, safety, family consent, care agreement, and marketing claims are reviewed before broad launch.

Founder and legal reviewer

Needs human review

Support ownershipFeedback, account, privacy, safety, and tester-report routes have named owners and response rules.

Support lead

Needs owner assignment

Deploy inspectVercel production deployment is Ready, canonical domain points to it, and no secret values appear in notes.

Engineering

Runs after production deploy

local evidence passedproduction providers are livetwo-user phone QA passedlegal and safety review has an ownersupport routes have ownersproduction deployment is Ready

Local tracker0 of 6 signed off

Launch is still waiting on sign-off proof.

Release evidencenpm run launch:evidence passes on the release branch and writes the public mobile visual manifest.Product and engineering

OwnerStatus

Live two-user QADedicated QA owner and guest complete create, invite, write, wait, reveal, reflect, and return on the canonical production domain.Launch QA owner

OwnerStatus

Legal and safety reviewPrivacy, terms, cookies, notifications, safety, family consent, care agreement, and marketing claims are reviewed before broad launch.Founder and legal reviewer

OwnerStatus

Support ownershipFeedback, account, privacy, safety, and tester-report routes have named owners and response rules.Support lead

OwnerStatus

Deploy inspectVercel production deployment is Ready, canonical domain points to it, and no secret values appear in notes.Engineering

OwnerStatus

Sign-off notes may include owners, commands, route names, pass or fail status, and safe screenshots. They must not include production secrets, OAuth tokens, passwords, one-time codes, journal answers, drafts, reveal text, invite links, support submissions, or crisis details.

Sign-off receiptSign-off proof is still missing.

6 sign-offs still need proof before broad launch. Keep the notes to owners, commands, route names, pass or fail status, and safe screenshots.

0 signed0 in review6 waitinglocal device onlyno private writing

Release evidence
Provider env
Live two-user QA
Legal and safety review
Support ownership
Deploy inspect

This receipt is local launch coordination only. It does not prove legal approval, provider setup, email delivery, support coverage, or broad launch readiness.

Legal review

Legal review packet for broad launch.

Use this packet to review the public trust surfaces together instead of one page at a time. It names who should review each area, what proof is needed, and what must stay out of review notes.

PLAYWRIGHT_BASE_URL=https://understandyoubetter.com npm run legal:evidence

Legal counselPrivacy and terms/privacy, /terms

Approve privacy promises, user responsibilities, account data controls, export and deletion language, and product limits.

Do the pages avoid therapy, legal, medical, diagnosis, custody, and crisis claims?
Are export, deletion, correction, and account verification expectations clear?
Do private journal answers, drafts, reveal text, solo notes, and reflections stay protected?

Legal counsel and productFamily and child consent/family-consent, /kids, /teens, /parents

Approve age-aware positioning, trusted-adult guidance, guardian-consent language, and no-hidden-monitoring boundaries.

Can a younger user understand they can pause and ask a trusted adult?
Is the product clearly not child surveillance or forced confession?
Is broad child-directed positioning held until consent policy is approved?

Privacy review ownerCookies and analytics/cookies

Approve essential storage, optional analytics, optional marketing storage, consent language, and the analytics allowlist.

Are analytics and marketing off unless the user allows them?
Does the allowlist block private writing, invite links, scores, and hidden profiling?
Can users reset optional choices without affecting private journals?

Operations and legal counselNotifications and marketing/notifications, /newsletter, /unsubscribe

Approve reminder consent, newsletter consent, unsubscribe behavior, sender identity, and the rule that emails never include private writing.

Are journal reminders separate from newsletters and marketing?
Do emails contain status only, with no private journal text or invite links?
Does unsubscribe work without asking for private writing?

Safety and support ownerSafety and support/safety, /support, /feedback

Approve support routing, safety escalation copy, feedback privacy filters, and the boundary that UYB is not emergency support.

Do urgent safety moments point to real-world help before product use?
Are support and feedback forms clear about leaving out private writing?
Are named owners assigned for account, privacy, safety, product feedback, and tester reports?

Safe evidence

route names
owner names or teams
approval status
public copy notes
safe screenshot descriptions
command output without secrets

Never include

journal answers
draft text
reveal text
solo notes
invite links
passwords
one-time codes
OAuth tokens
production secrets
crisis details

Legal review tracker0 of 5 review areas approved

Legal approval proof is still being gathered.

Privacy and termsApprove privacy promises, user responsibilities, account data controls, export and deletion language, and product limits./privacy, /termsLegal counsel

ReviewerStatus

Family and child consentApprove age-aware positioning, trusted-adult guidance, guardian-consent language, and no-hidden-monitoring boundaries./family-consent, /kids, /teens, /parentsLegal counsel and product

ReviewerStatus

Cookies and analyticsApprove essential storage, optional analytics, optional marketing storage, consent language, and the analytics allowlist./cookiesPrivacy review owner

ReviewerStatus

Notifications and marketingApprove reminder consent, newsletter consent, unsubscribe behavior, sender identity, and the rule that emails never include private writing./notifications, /newsletter, /unsubscribeOperations and legal counsel

ReviewerStatus

Safety and supportApprove support routing, safety escalation copy, feedback privacy filters, and the boundary that UYB is not emergency support./safety, /support, /feedbackSafety and support owner

ReviewerStatus

This packet organizes review evidence only. It is not legal advice, does not replace counsel, and must not store private writing, account secrets, invite links, or crisis details.

Legal review receiptLegal review still needs approval proof.

5 legal review areas still need approval proof before broad launch. Store owner names and status only.

0 approved0 reviewing5 waitinglocal device onlyno private writing

Privacy and terms
Family and child consent
Cookies and analytics
Notifications and marketing
Safety and support

This receipt is local coordination only. It stores reviewer names and approval status only. It is not legal advice and does not prove counsel approval, provider setup, email delivery, live support coverage, child-directed launch approval, or broad launch readiness.

This packet organizes review evidence only. It is not legal advice, does not replace counsel, and must not store private writing, account secrets, invite links, or crisis details.

Analytics review

Privacy-safe analytics review.

Use this before optional product analytics is enabled. The goal is to learn where people get stuck without turning private writing into measurement data.

npm test -- tests/trust-pages.test.js && npm run copy:check

/cookies/launch-readiness

Product and privacy reviewConsent gate

Product analytics stays off unless the user allows it, and marketing consent stays separate.

Cookie preferences show analytics as optional.
Marketing storage is not bundled with product analytics.
Users can reset optional choices without affecting private journals.

Engineering and privacy reviewSafe event allowlist

Only reviewed status, route group, device class, preference, and reliability events are allowed.

No raw journal IDs, invite codes, profile names, emails, or free text are allowed.
New event families are blocked until product and privacy review approve them.
Allowed properties stay short, bounded, and useful for fixing broken flows.

Legal counsel and engineeringNever collect fields

Private writing and direct account secrets are excluded before any analytics provider is connected.

Never collect journal answers, drafts, solo notes, vent text, reveal text, or reflections.
Never collect invite links, passwords, one-time codes, OAuth tokens, production secrets, or crisis details.
Never use analytics to score, summarize, train on, or market from private writing.

Launch QA ownerLaunch proof

The public cookie page and launch readiness page both show the analytics boundary before broad launch.

Run npm test -- tests/trust-pages.test.js.
Run npm run copy:check.
Review /cookies and /launch-readiness on a phone before enabling any analytics provider.

Allowed only after consent

route groups
device class
signed-in state
flow step labels
draft recovery status
journal status labels
preference state
safe error kind
offline recovery state

Blocked always

journal answers
draft text
solo notes
vent text
reveal text
private reflections
invite links or codes
names or email addresses
focus notes
comfort notes
scores
hidden profiles

Analytics stays review-only until consent, privacy review, and a provider setup are approved. It must never read, score, summarize, train on, or market from private journal content.

Live smoke

Run the live production smoke in this order.

Use this only after live Clerk keys, app URL, Resend, cron secret, and QA accounts are configured. It turns production launch into observable evidence instead of a guess.

strict readiness passes with Vercel production valuesdedicated QA owner and guest accounts existlegal and consent review has an ownersupport ownership is assignedno customer journal is used for testing

1
Public domainPLAYWRIGHT_BASE_URL=https://understandyoubetter.com npm run test:e2e:public -- --project=mobile-chromium/, /start-here, /help, /safety, /privacy, /launch-readiness
Public routes load from the canonical domain with no horizontal scroll, visible focus, readable first viewport, and private routes excluded from discovery.
2
Google sign-inOpen /sign-in on a phone and sign in with the dedicated QA owner account/sign-in, /dashboard, /profile
Clerk uses live keys, Google OAuth completes, profile loads, and no development-key warning appears in production browser logs.
3
Two-person journalUYB_RUN_AUTH_E2E=1 PLAYWRIGHT_BASE_URL=https://understandyoubetter.com npm run test:e2e:live -- --project=mobile-chromium --reporter=line/pair/new, /pair/[inviteCode], /pair/[inviteCode]/question/[sessionId]
Passed on production after QA cleanup: Clerk ticket sign-in, profile setup, invite, join, start question, draft recovery, both sides save, reveal, private reflection, second journal creation, and final QA cleanup.
4
Email and cronnpm run production:email-evidence/profile, /notifications, /updates, /api/notifications/send
Resend, sender, app URL, and cron secret are configured. A QA-only status notification is marked sent and then deleted. Test reminder content contains status only and no journal writing.
5
Support and account requestsUse QA account to submit product and account feedback without private writing/feedback?topic=product, /feedback?topic=account, /support
Feedback stores route, topic, safe details, and support ownership path without journal answers, draft text, reveal text, or secrets.
6
Deployment inspectvercel inspect <production-deployment-url>Vercel production deployment
Production deployment reports Ready, the canonical domain points to the latest build, and no secret values are copied into notes.

canonical domain loadsGoogle sign-in workstwo-person reveal worksemail reminders exclude private textsupport reports exclude private writingVercel deployment is Ready

Live smoke notes may include route names, commands, pass or fail status, screenshots without private text, and provider status labels. They must not include passwords, OAuth tokens, production secrets, journal answers, drafts, reveal text, invite links, support submissions, or crisis details.

QA proof

Prove the live two-person flow without collecting private writing.

Use this after redeploying production. It turns founder testing into a repeatable QA packet for Google sign-in, private writing, invite join, reveal, updates, and support.

1Release proof

npm run launch:evidenceNeeds Vercel CLI access

Confirms tests, copy checks, public mobile smoke, public screenshot evidence, pulled Vercel Production readiness, database shape, and build still pass before the production deployment is trusted.

Evidence: Record command, exit status, commit, public mobile smoke status, and the public visual manifest path. Do not copy private screenshots or secrets into notes.

2Provider proof

npm run readiness:check -- --vercel-values --strict --dbNeeds Vercel production values

Confirms live Clerk keys, one matching key pair, app URL, Resend, cron secret, QA accounts, and database readiness.

Evidence: Record pass or fail status and key names only. Never record provider values.

3Owner proof

Sign in as the QA owner on a phoneNeeds live Clerk

Create a journal, choose a side label, save private writing before anyone joins, and confirm the app explains sharing without blocking writing.

Evidence: Capture route names, visible status labels, and safe screenshots with fixture text only.

4Guest proof

Open the invite as the QA guest on a second browser or phoneNeeds QA guest

Join from the private invite, choose the other side, answer the same guided question, and confirm each person sees waiting and reveal states clearly.

Evidence: Record invite join, save state, waiting state, reveal state, and dashboard or journey return state.

5Notification proof

npm run production:email-evidenceNeeds Resend and cron

Confirm updates and emails describe status only, respect preferences, and never include journal answers, drafts, reveal text, or vent text.

Evidence: Record sender, preference state, delivery status, and that private writing was excluded.

6Support proof

Submit a safe tester reportNeeds support owner

File one feedback item with screen, expected result, actual result, device, and impact so support can help without collecting private content.

Evidence: Record route, topic, severity, support owner, and safe screenshot description.

Safe evidence

route names and timestamps
QA account labels, not customer emails
pass or fail status
fixture text screenshots only
device, browser, and viewport
provider key names, never values

Never collect

journal answers
drafts
reveal text
vent entries
invite links
passwords or one-time codes
OAuth tokens
production secrets
crisis details

owner can write before guest joinsguest sees the same guided questionboth saves survive refreshreveal opens only after both saveupdates show status without private textsupport report has a named owner

QA proof can show what happened, where it happened, and whether it passed. It must not preserve private writing, invite links, account secrets, production secrets, OAuth data, one-time codes, support submissions, or crisis details.

Fix order

Fix the launch blockers in this order.

The current blocker set is mostly provider configuration. Work from least risky to most sensitive, then run strict readiness.

npm run readiness:check -- --vercel-values --strict --db

Can test now

public smoke routes
signed-out private route redirects
production Google and Clerk sign-in QA
two-user authenticated journal QA
copy quality
build and unit tests

Blocked until setup

email reminder delivery
scheduled notification delivery

1
Set the canonical app URLvercel env add UYB_APP_URL production
Do this first because email links, cron routes, metadata checks, and support links all need one production home.
UYB_APP_URL
Value: https://understandyoubetter.comEvidence: readiness:check shows Canonical app URL ok.
2
Switch Clerk to live production keysvercel env add NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY production && vercel env add CLERK_SECRET_KEY production
This unlocks real production sign-in checks and keeps test Clerk keys out of the broad launch path.
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEYCLERK_SECRET_KEY
Value: Use pk_live and sk_live from the production Clerk instance.Evidence: readiness:check shows both Clerk checks ok.
3
Connect Resend and the sendervercel env rm RESEND_API_KEY production && vercel env add RESEND_API_KEY production && vercel env add UYB_EMAIL_FROM production
If Vercel shows RESEND_API_KEY but readiness says missing key, replace the empty value. After that, send only status reminders, never private writing.
RESEND_API_KEYUYB_EMAIL_FROM
Value: Use a non-empty production Resend key and a verified sender on the UYB domain.Evidence: readiness:check -- --vercel-values shows Email provider key ok, production:email-evidence marks a QA-only status email sent, unsubscribe works, and no private journal text appears in email.
4
Protect scheduled notification sendsvercel env add CRON_SECRET production
This lets scheduled notification routes run without exposing a public trigger for reminder sending.
CRON_SECRET
Value: Use a long random value stored only in Vercel and local ignored env files.Evidence: readiness:check shows Notification cron secret ok.
5
Create dedicated Clerk QA accountsvercel env add UYB_QA_OWNER_EMAIL production && vercel env add UYB_QA_OWNER_USER_ID production && vercel env add UYB_QA_GUEST_EMAIL production && vercel env add UYB_QA_GUEST_USER_ID production
This is the gate for authenticated two-person QA without using a founder, tester, or customer journal. Each QA account needs an email plus either a Clerk user ID or a password.
UYB_QA_OWNER_EMAILUYB_QA_OWNER_USER_ID or UYB_QA_OWNER_PASSWORDUYB_QA_GUEST_EMAILUYB_QA_GUEST_USER_ID or UYB_QA_GUEST_PASSWORD
Value: Use two production QA accounts that never hold private customer content. Use user IDs when possible, or passwords only in Vercel if the live E2E path requires them.Evidence: The two-user QA flow creates, writes, waits, reveals, reflects, and returns successfully.

Only paste secret values into Vercel or ignored local env files. Public docs, chat, screenshots, and support tickets should show key names, not values.

QA matrix

What can be tested right now.

Use this matrix to separate production smoke checks from authenticated and provider-dependent checks.

4 ready now1 waiting on setup

Ready nowPublic mobile smoke

/

Check homepage, help, safety, questions, kids, notifications, sitemap, robots, and llms.txt without signing in.

Playwright mobile viewport. Evidence: 200 responses, no horizontal scroll, first-viewport obstruction checks, readable contrast samples, keyboard skip access, comfortable tap targets, canonical metadata, public routes only.

Ready nowSigned-out boundaries

/dashboard, /updates, /pair/test/question/test

Confirm private routes redirect to sign-in and preserve the return URL.

curl or Playwright. Evidence: Redirect lands on /sign-in with redirect_url intact.

Ready nowProfile care agreement

/profile

Confirm profile saving and profile-to-journal setup require the care agreement, while no birthdate or age field is collected.

Unit test and authenticated profile QA. Evidence: Profile action redirects missing agreement submissions and the visible agreement explains consent, privacy, safety, and UYB limits.

Ready nowTwo-person journal flow

/pair/new

Create a journal, write as owner, join as guest, write the second side, open the reveal, and confirm history and updates agree.

UYB_RUN_AUTH_E2E=1 PLAYWRIGHT_BASE_URL=https://understandyoubetter.com npm run test:e2e:live -- --project=mobile-chromium --reporter=line. Evidence: Production QA passed with dedicated owner and guest accounts. Repeat after major auth, journal, or database changes.

Needs provider envEmail, cron, and reminder flow

/profile, /updates

Verify Resend, sender, app URL, cron secret, and notification preferences before treating reminders as live.

npm run readiness:check. Evidence: Readiness check passes and test emails never include private journal writing.

Do not use private customer journals for QA. Use dedicated production QA accounts once they are configured.

Discovery

Search and AI recommendation readiness.

This gate keeps public discovery useful without turning private writing into public content. It is for Google, AI assistants, and humans who need to understand UYB before signing in.

Public mapOnly public routes belong in discovery files

Sitemap, robots, and llms.txt expose help, safety, guides, blog, newsletter, and legal pages while keeping private journal routes out.

Evidence: Public mobile smoke checks robots.txt, sitemap.xml, and llms.txt for public-only boundaries.

MetadataEvery important public page explains itself

Public pages need titles, descriptions, canonical URLs, and social preview fields so search and AI assistants can classify the product accurately.

Evidence: Metadata tests cover public discovery pages and dynamic guide or blog entries.

Structured dataUse structured data where it helps

FAQ, guide, blog, question, feature, and readiness pages should expose JSON-LD only for public product education, never private journal content.

Evidence: Trust-page tests check FAQPage, ItemList, Article, BlogPosting, and WebPage usage on public routes.

Privacy boundaryAI summaries must not expose private writing

Public pages can be summarized, but private journal answers, drafts, solo notes, reveal text, invite links, account details, and OAuth data stay out.

Evidence: llms.txt states the private-content boundary and robots disallows private app routes.

npm test -- tests/trust-pages.test.jsnpm run test:e2e:public -- --project=mobile-chromiumnpm run copy:check

Snippet review

Search and AI snippet review.

Review how UYB could be summarized by search results, AI assistants, and link previews before broad launch. The goal is useful discovery without private content leakage or inflated claims.

PLAYWRIGHT_BASE_URL=https://understandyoubetter.com npm run visual:mobile

Home and featuresSnippet should explain UYB as a private guided journal and one-to-one reflection app.

//features/start-here

Target snippet

A private guided journal for softer one-to-one conversations, with writing-first, share-by-choice, and reveal-after-both-answer boundaries.

Block this wording

Do not call UYB therapy, a public feed, AI relationship advice, hidden monitoring, or a place where private answers are visible.

No therapy claim, public feed claim, private answer text, or hidden monitoring promise appears.

Safety and familySnippet should make age-aware safety, trusted-adult help, and no-hidden-monitoring boundaries clear.

/safety/kids/parents/family-consent

Target snippet

Age-aware guidance for kids, teens, parents, and adults, with pause, consent, trusted-adult help, and real-help-first safety boundaries.

Block this wording

Do not imply emergency support, surveillance, diagnosis, forced confession, legal approval, or hidden parent access.

Danger routes to real-world help and UYB is not framed as emergency support or surveillance.

Questions and guidesSnippet should describe reviewed prompts and guidance without implying live AI advice or diagnosis.

/questions/question-studio/guides/faq/q-and-a

Target snippet

Reviewed question examples and guides that help people choose a safer first step without submitting private answers.

Block this wording

Do not imply live AI counseling, diagnosis, personalized therapy, private-answer analysis, or public Q&A replies.

Public examples stay reviewed, private answers stay out, and no AI-generated therapy claim appears.

Discovery filesDiscovery files should expose public education routes and exclude signed-in private journal routes.

/sitemap.xml/robots.txt/llms.txt

Target snippet

Public discovery files describe product, guide, help, safety, legal, blog, and newsletter routes only.

Block this wording

Do not expose private app routes, invite codes, account routes, answers, drafts, reveals, support submissions, or OAuth data.

Private app routes, invite links, account routes, answers, drafts, reveals, and support submissions stay out.

Snippet target receiptEach route group now has a target snippet and a blocked wording list so reviewers can compare search results, AI summaries, and link previews against the same safe language.

target copyblocked claimspublic routes onlyno private content

The snippet target is review guidance only. It does not prove indexing, ranking, Search Console coverage, legal approval, analytics approval, provider setup, or broad launch readiness.

Local snippet review tracker0 of 4 route groups passed

Search and AI snippet proof still needs review passes.

public routes onlyno private contentbounded claimsage-aware wordingAI-safe summary

Home and featuresSnippet should explain UYB as a private guided journal and one-to-one reflection app.

//features/start-here

No therapy claim, public feed claim, private answer text, or hidden monitoring promise appears.

Status

Safety and familySnippet should make age-aware safety, trusted-adult help, and no-hidden-monitoring boundaries clear.

/safety/kids/parents/family-consent

Danger routes to real-world help and UYB is not framed as emergency support or surveillance.

Status

Questions and guidesSnippet should describe reviewed prompts and guidance without implying live AI advice or diagnosis.

/questions/question-studio/guides/faq/q-and-a

Public examples stay reviewed, private answers stay out, and no AI-generated therapy claim appears.

Status

Discovery filesDiscovery files should expose public education routes and exclude signed-in private journal routes.

/sitemap.xml/robots.txt/llms.txt

Private app routes, invite links, account routes, answers, drafts, reveals, and support submissions stay out.

Status

This review stores route group labels and pass status only on this device. It must not include private journal answers, draft text, reveal text, invite links, account details, OAuth data, support submissions, crisis details, screenshots with private writing, or production secrets.

Snippet review receiptPublic discovery still needs local pass marks before broad launch.

0 passed0 reviewing4 waitinglocal device onlyno private content

Home and features
Safety and family
Questions and guides
Discovery files

This receipt is local coordination only. It does not prove search-console indexing, legal approval, support coverage, provider setup, analytics approval, or broad launch readiness.

SEO and AI discovery can explain the product, audiences, safety limits, and help content. They must not quote, infer, expose, index, or summarize private journals, drafts, solo notes, reveals, invite links, account data, or support submissions.

Manual check

Before broad launch, check these by hand.

Automated tests help, but UYB still needs real-device review because people use it during emotional moments.

FounderReal account flow

Needs real-device pass

Create two production accounts, start a journal, write both sides, open the reveal, and confirm the dashboard, updates, and journey history all agree.

Legal reviewLegal and safety copy

Needs counsel review

Review privacy, terms, cookies, notifications, safety, age-related language, consent language, and all non-therapy boundaries before broad rollout.

Product and legalCare agreement

Built, needs launch review

Confirm the Profile care agreement is understandable for younger users, clear enough for adults, and aligned with legal review before broad rollout.

OperationsEmail and notifications

Provider-ready

Confirm Resend is connected in production, send a profile test update, verify reminder preference headers, verify unsubscribe, verify the cron secret, and check that email never includes private writing.

SupportSupport routing

Needs owner assignment

Decide who receives feedback, abuse concerns, account questions, billing questions, and launch tester reports.

Product QAHuman copy QA

Automated gate ready

Run npm run copy:check before launch changes ship, then read the touched screens on a phone for plain, human wording.

Product QAAccessibility and mobile

Needs device pass

Test keyboard skip navigation, mobile tap targets, no horizontal scroll, first-viewport obstruction, readable contrast, draft recovery, and reduced guessing across the main flows.

Support owners

Assign support ownership before broad launch.

UYB has the routes. Launch still needs named owners so feedback, account requests, safety concerns, privacy questions, and tester reports do not pile into one unclear inbox.

Product ownerProduct feedback/feedback?topic=product

Review for patterns before turning it into product work.

Safe details

screen name
device
expected action
what felt confusing

Never include

journal answers
draft text
reveal text

Account support ownerAccount requests/feedback?topic=account

Verify identity before export, deletion, correction, sign-in, or shared-journal review.

Safe details

request type
account email if needed
device and browser

Never include

passwords
one-time codes
private writing

Safety escalation ownerSafety concerns/safety

Point to real-world help first when danger, coercion, abuse, crisis, or self-harm may be involved.

Safe details

screen where concern appeared
general safety category
whether urgent help is needed

Never include

crisis details in public forms
another person's private writing
threat transcripts

Privacy review ownerPrivacy or legal/privacy

Route privacy, terms, cookies, notification, retention, consent, export, and deletion questions carefully.

Safe details

request type
public policy page
account marker if needed

Never include

journal content
invite links
OAuth tokens

Launch QA ownerLaunch tester reports/launch-readiness

Triage as bug, UX, copy, feature, safety, parked, or decision needed before implementation.

Safe details

test date
route
device
result
safe screenshot description

Never include

real private journal text
customer account secrets
production secrets

every route has a named human owneraccount requests require identity verificationsafety concerns point to real-world help firstsupport never asks for private journal writingtester reports become triaged product work

Support tracker0 of 5 routes ready

Support ownership is still waiting on proof.

Product feedbackReview for patterns before turning it into product work./feedback?topic=product

OwnerStatus

Account requestsVerify identity before export, deletion, correction, sign-in, or shared-journal review./feedback?topic=account

OwnerStatus

Safety concernsPoint to real-world help first when danger, coercion, abuse, crisis, or self-harm may be involved./safety

OwnerStatus

Privacy or legalRoute privacy, terms, cookies, notification, retention, consent, export, and deletion questions carefully./privacy

OwnerStatus

Launch tester reportsTriage as bug, UX, copy, feature, safety, parked, or decision needed before implementation./launch-readiness

OwnerStatus

Support ownership can store route names, safe summaries, device details, and status. It must not store journal answers, drafts, reveal text, passwords, one-time codes, OAuth tokens, or production secrets.

Support owner receiptSupport ownership still needs names.

5 support paths still need a ready owner before broad launch. Store owner names or team names only.

0 ready0 assigned5 waitinglocal device onlyno private writing

Product feedback
Account requests
Safety concerns
Privacy or legal
Launch tester reports

This receipt is local coordination only. It does not prove live support coverage, legal approval, account verification, emergency response, email delivery, or broad launch readiness.

Pattern reviewProduct feedback

Review during the next product triage pass.

Link the accepted issue to a test, evidence note, or parked decision.

Identity requiredAccount request

Confirm the request type, then verify the account before export, deletion, correction, or sign-in action.

Record the request type, verification status, action taken, and safe account marker only.

Careful reviewPrivacy or legal

Point to the public policy page first, then collect only the request type and safe account marker if needed.

Record route, policy area, owner, decision, and whether follow-up is needed.

Use real help firstSafety concern

Tell the person to use emergency, crisis, trusted adult, or local support before product troubleshooting.

Record that real-world help was shown and whether product copy or routing needs review.

Launch QALaunch tester report

Classify as blocked, confused, polish, safety, account, legal, parked, or decision needed.

Record route, device, expected result, actual result, severity, owner, and proof command.

Safe records

route or policy page
request type
device and browser
expected result
actual visible result
safe account marker if needed
owner and status

Never record

journal answers
draft text
solo notes
vent text
reveal text
invite links
passwords
one-time codes
OAuth tokens
crisis details

Support operations should prove the request was routed and handled. They must not become a second place to store private writing, account secrets, invite links, or crisis details.

Active

Safety and trust

UYB keeps the emotional boundary visible before people write, reveal, or invite someone.

Private answers stay closed until both people save their side.
There is no public feed, open comment thread, random matching, or hidden monitoring.
Safety pages explain that UYB is not therapy, crisis care, legal advice, medical advice, diagnosis, or emergency support.
Kid, teen, parent, and adult language is written for consent, clarity, and age-aware support.
Profile saving and profile-to-journal setup require a care agreement for consent, privacy, safety, and product limits.

Active

Core journal flow

The app supports solo thinking, paired journals, guided questions, waiting states, and reveal moments.

People can create a private journal, write before the other person joins, and share when they are ready.
Question selection is guided, not left to the user during emotional friction.
Reveals include private feeling markers and reminders to read for understanding.
Journal history, milestones, and dashboard actions show what to do next.

Active

Mobile and accessibility

UYB is designed around small screens, large tap targets, clear status, and calmer transitions.

Primary journal actions are visible in mobile-friendly flows with less top-to-bottom hunting.
Draft recovery reduces the risk of losing writing after a call, reload, or device interruption.
Public pages use semantic headings, readable contrast, responsive layouts, structured metadata, and a public accessibility statement.
Motion and visual polish stay supportive instead of hiding the next action.
Copy quality checks keep unnecessary em dashes out of app and library source.

Provider-ready

Notifications and email

The product can support reminders and marketing with separate consent paths.

In-app updates can cover journal creation, joined invites, saved answers, and ready reveals.
Email reminders are wired for event-specific choices once the email provider key is live.
The scheduled sender requires a cron secret and redacts provider failure details from client-visible responses.
Reminder emails include preference headers so mail clients can point users back to notification settings.
Newsletters and marketing use separate opt-in language and unsubscribe paths.
Reminder content must never include private journal answers, drafts, or reflections.

Needs review

Legal and launch review

The required trust surfaces exist, but formal review still matters before broad launch.

Privacy, terms, cookie, notification, safety, help, and Q&A pages are present.
Legal counsel should review the legal pages, age-related language, consent language, and marketing claims.
The product should avoid therapy, medical, legal, crisis, diagnosis, or emergency-support claims.
A final launch pass should check real accounts, production domains, email delivery, analytics consent, and support routing.

Active

Search and AI discovery

Public pages are structured so people and recommendation systems can understand what UYB is for.

Sitemap and robots expose public help, guide, safety, newsletter, and legal pages while keeping private journal routes out.
Public pages use canonical URLs, Open Graph, Twitter metadata, and JSON-LD where useful.
Copy explains the product in plain language for parents, teens, partners, and families.
Private journal content stays out of public search and public metadata.