Ideas: Improving signup-to-first-session conversion

[alexesprit]

Hey Oscar!

It's not an issue, just a kind of ideas/discussion (maybe it's worth enabling discussions there?). I saw your comment about increasing conversion (onboarding -> push stats), and now I'm wondering how this can be solved. So I chatted with Opus and Gemin about that. Below are the suggestions.

Suggestions (Click to expand)

Live onboarding step 3 (polling for first session)

The current Step 3 of onboarding shows a static mock terminal output and two exit links ("Done! Take me to my feed" / "I'll do this later"). The user copies the CLI command, leaves the page, and may never come back. The moment of highest motivation (right after signup) is wasted.

The change

Replace the static mock with a live component that polls for the user's first session and reacts when data arrives.

Step 1: Add a lightweight polling endpoint

Create GET /api/usage/status — returns whether the current user has any daily_usage rows, and if so, returns summary stats (total cost, sessions, top model, streak).

Step 2: Rewrite Step3LogSession with three states

State A — Waiting (initial):

• The npx straude@latest copy-to-clipboard command (keep as-is)
• Instead of the static mock output, show a pulsing/animated "Listening for your first session..." indicator
• Poll /api/usage/status every 3-5 seconds
• "I'll do this later" skip link stays

State B — Data detected (poll returns data):

• Stop polling
• Animate transition to show real stats — actual cost, tokens, models from the session they just pushed
• Show their leaderboard rank ("You're feat: roadmap entropy detector #23 of 891 users")
• A small celebration moment (checkmark animation, confetti, whatever fits the design)
• CTA: "View your profile →" linking to /u/{username}

State C — Skip (unchanged):

• "I'll do this later → Go to feed" stays as the escape hatch

Step 3: That's it.

No changes to the CLI, no changes to the submit API, no new emails. The onboarding page just becomes aware of when data arrives and reacts to it in real time.

Why this matters

The key difference: instead of the user leaving the onboarding page to go check if it worked, the onboarding page tells them it worked and rewards them on the spot. The loop closes in the same browser tab where the motivation lives.

---

CLI updates

Reverse the funnel: CLI first, signup second

Right now: landing page → signup → run CLI → see value.

Run npx straude (no auth needed) → see your stats locally in the terminal → "Want to save this and compete on the leaderboard? Sign up at straude.com" → signup with data already ready to push.

Everyone who signs up through this path has already seen value and has data. Zero dead signups. The website becomes the upgrade, not the starting point.

Backfill on first push

We mentioned this earlier but it's worth repeating — right now the first run defaults to today only. If the user hasn't used Claude Code today, they get "No usage data found" and bounce. Changing the first-run default to scan more days would dramatically increase the chance of a successful first push and create an instant "wow" moment with a populated profile.

##CLI verify page redirect

The /cli/verify page is a dead end if the user isn't logged into the web app (e.g. in a system with multiple browsers). Currently (app/cli/verify/page.tsx:36) it just shows "You must be logged in to authorize the CLI." with no link or redirect. The user has to manually navigate to /login, log in, and somehow get back to the verify URL — likely running out of the CLI's 5-minute polling timeout.

What do you think about it?

[ohong]

Hey @alexesprit thanks for the amazing suggestions! I'll add them to docs/ROADMAP.md and think through the best way to move forward. Cutting time-to-value down and thoughtfully re-engaging users who might've forgotten about Straude (ppl are busy) are top-of-mind right now. Thinking through too whether we want syncing to Straude should be an active decision from the user (sync -> check feed / leaderboard loop) or something that just happens in the background. Each has their pros & cons.

I've also opened up Discussions on GH; great idea 👍