Current flow
- User submits
/register on the marketing site
- Platform creates congregation + sends verification email
- User reads email, clicks link
- User lands on app (or marketing site)
- User must re-enter email + password to log in
Step 5 is the friction. Each step in this chain is a 10\u201330% drop-off opportunity, and asking users to re-type their just-set password right after clicking an email link is the weakest point.
Proposal
The verification email link should auto-create a session (single-use, signed token) and land the user directly inside the app dashboard. Eliminate the manual login step.
Implementation likely involves:
- A signed token in the verification URL (short TTL, single-use)
- An endpoint (
/auth/verify) that consumes the token, marks the email as verified, creates a session, and redirects to the dashboard
- Token issuance from the platform when the email is sent (or by the main app when the link is generated)
Out of scope
Resend-verification UX is tracked separately in unitae-platform (/api/resend-verification endpoint) and unitae-website (UI on success page).
Current flow
/registeron the marketing siteStep 5 is the friction. Each step in this chain is a 10\u201330% drop-off opportunity, and asking users to re-type their just-set password right after clicking an email link is the weakest point.
Proposal
The verification email link should auto-create a session (single-use, signed token) and land the user directly inside the app dashboard. Eliminate the manual login step.
Implementation likely involves:
/auth/verify) that consumes the token, marks the email as verified, creates a session, and redirects to the dashboardOut of scope
Resend-verification UX is tracked separately in
unitae-platform(/api/resend-verificationendpoint) andunitae-website(UI on success page).