Onboarding Automation: Guided Intelligence Setup with Stripe Trial Conversion

Activation rate is the metric that separates platforms that retain from platforms that churn. A user who completes a meaningful action within the first session is orders of magnitude more likely to convert from trial to paid than one who signs up and sees a blank dashboard.

The Avo intelligence platform launched with a functional but inert post-signup state. Users arrived at the dashboard with no prefilled watchlist, no context about the five market regimes the system tracked, and no demonstration that the intelligence layer was already computing on their behalf.

The business had a secondary problem: trial-to-paid conversion required the user to voluntarily navigate to a pricing page. There was no guided moment where the platform translated the user's stated preferences into a live intelligence preview and then connected that preview to the upgrade path.

The onboarding flow was a three-step wizard rendered at /onboarding for any authenticated user whose Clerk publicMetadata.onboarded key was absent or false. Middleware redirected post-login traffic to /onboarding for this population.

Step 1 collected crypto category preferences across nine categories. Each category carried four pre-seeded symbols. The user selected any combination and the system derived a deduplicated symbol list capped at 16 entries. Step 2 fetched live intelligence for those symbols from /api/onboarding/intelligence, which proxied requests to the same Redis-backed intelligence API serving production users. Each symbol returned its market regime classification, regime confidence score, active timeframe count, and top three correlation pairs. This was the platform demonstrating its value with the user's own stated preferences, not with a static demo. Step 3 was the completion step, which updated Clerk publicMetadata with onboarded: true.

The /api/onboarding/intelligence route accepted a symbols array in the request body and batched calls to the intelligence layer. For each symbol, it scanned the Redis keyspace for argus:regime:*, argus:novelty:*, and argus:correlation:* keys using the same pattern-matching logic as the production /api/intelligence/[symbol] route.

The onboarding completion and session invalidation: the POST /api/onboarding/complete handler retrieved the current Clerk session token and called invalidateSessionCache before returning. Without this invalidation, the middleware would have redirected the user back to /onboarding on the next navigation because the middleware read stale data.

The paid gate logic: the RegimeCard component accepted an isPaid boolean prop. Paid users saw full correlation data and all available regime timeframes. Free users saw a blurred overlay on correlation details with an inline upgrade prompt. The preview was functional enough to demonstrate value without exposing the full data payload.

The onboarding wizard reduced the post-signup dead-end state to zero. Every authenticated user without the onboarded flag hit the wizard before reaching the dashboard. The intelligence preview step loaded in under 1.2 seconds for a 16-symbol batch. The completion API updated Clerk metadata in under 200 milliseconds.