Status: v2 (marketing-strategist, 2026-04-29 UTC). Decisions 1-4 resolved by Kristerpher (PR #465 review). Decision 5 pending business-legal-researcher analysis (in flight, parallel dispatch). Nothing in this doc ships until Decision 5 is resolved.
The modal visitor arrives via one of four routes:
| Source | State of intent | What they need in the first 10 seconds |
|---|---|---|
| Podcast ad / social mention | Curious; no prior exposure | "What is this thing, actually?" — they need a concrete task to witness |
| Sent by a current Founder | Comparing; moderate intent | "Is this real, or vaporware?" — they want proof of the paper-first claim |
| Returning from getraxx.com | Price-checking or skeptical | "Does this justify $29/mo?" — they want to feel the product before paying |
| Organic search / SEO | Lowest intent, widest funnel | "What's the options research space?" — will bounce unless one specific thing grabs them |
Modal visitor: The podcast/ad visitor who has heard "test before you risk" and wants to see what that means in practice. This is the most important visitor because (a) it's the majority of pre-GA traffic, (b) they arrive with a clear hook but no context, and (c) they are one wow-moment away from signing up.
Design the flow for this visitor. The skeptical returning visitor and the low-intent search visitor are secondary; the flow can serve them incidentally but should not be diluted to accommodate them.
The modal visitor has curiosity, not conviction. The flow must produce conviction — not by explaining the product, but by letting them experience one complete unit of value: "tell me your number, I'll find the structure, you'll see the fill." From that one rep, they understand what Raxx is. Everything else is polish.
The demo must answer one question in under 90 seconds: "If I paper-traded this structure right now, what would I see?"
| Surface | Why it's in | Interaction type |
|---|---|---|
| Seed capital + weekly/daily goal sliders | The opening question that makes everything else concrete; dual sliders expose feasibility constraints in real time | Interactive — user adjusts two sliders; feasibility readout updates live |
| Ticker picker (3-5 tickers, each with a one-line explainer) | Core personalization; lets the visitor recognize an instrument they actually trade | Interactive — user selects one ticker from a small labeled set |
| AI structure proposals (2-3 candidates) | The core differentiator; impossible to communicate in copy alone | Interactive — user clicks a candidate to drill in |
| Proposal detail — strikes, widths, deltas, historical win-rate | Proof of the "no vibes" claim | Read-only (user inspects, does not modify) |
| Paper fill (simulated) | The "paper-first" promise made tangible | Interactive — user clicks "Paper it"; sees the fill receipt |
| Paper trade ledger (single entry) | Proves the audit-trail claim | Read-only — ledger shows the just-filled trade |
| Surface | Why it's in | Note |
|---|---|---|
| Options chain snippet (one underlying) | Shows the chain is real, not a toy | Pre-rendered with real but static historical data |
| P/L diagram for the selected structure | Confidence Engine visual; builds trust in the UI quality | Pre-rendered against proposal strikes |
| Surface | Why it's out |
|---|---|
| Live market quotes | Operational cost (Alpaca Algo Trader Plus $90.75/mo) and real-time data complexity; not worth it for an ephemeral session. Static data serves the demo purpose. |
| Full options chain (all expirations, all strikes) | Data volume + rendering cost; the demo needs one row to prove the concept |
| Backtesting lab | Too complex to compress into a demo-length flow; risks confusing the modal visitor who just wants to see one trade proposed and filled |
| Iron-condor screener | Pre-launch: not yet built to GA quality; surfacing a half-finished feature harms conversion |
| Strategy comparison | Same — pre-launch, not ready for public surface |
| Account settings / broker connection | There is no account; these are no-ops in an ephemeral session |
| Portfolio / P/L dashboard | Requires historical data that a new session doesn't have; would display empty states that look like bugs |
Guiding principle: The demo is a one-rep rep, not a feature tour. One complete loop — number in, structure proposed, paper filled, ledger shown — is more converting than six half-experiences.
| Option | Mechanic | Retention complexity | Cost |
|---|---|---|---|
| (a) Ephemeral session — resets on close | All state in memory; cleared on tab close / session expiry (30 min TTL, confirmed). Server generates the proposal on-demand; no user record persists. | Low — no DB writes | Minimal; a stateless demo API endpoint |
| (b) Cookie-scoped state — persists the visit, not the account | State written to localStorage / sessionStorage; proposal data survives a page refresh but dies when the session cookie is cleared. No server account created. | Medium — state management across page loads | Low-to-moderate; browser storage only |
| (c) Fully-faked dataset — no real market data, all fabricated | Static mock data. No API calls. No session state. | Lowest — pure static | Lowest |
Why: Option (c) risks the demo feeling fake — if the visitor looks up the SPX strikes later and they don't match, trust is lost. Option (b) adds state management complexity across page loads for marginal gain (the modal visitor is not coming back mid-session). Option (a) is the right balance: the proposals and the chain data are generated against real historical data (static snapshot — no live feed needed), making the output authentic, and the session evaporates cleanly on close. There is no user record to GDPR-manage, no account to orphan, and no "you have unsaved changes" UI to build.
What "ephemeral" means in practice: One backend endpoint generates a demo session token (UUID, no PII). The token gates the proposal call and the paper-fill call. Session TTL is 30 minutes server-side (confirmed). On expiry or on tab close, the token is gone. No email, no passkey, no DB user row.
What "real historical data" means: The proposal engine runs against a static snapshot of chain data from a fixed recent date (e.g., the last Friday close). Not live. Not stale-on-purpose. Just frozen-real, refreshed periodically (weekly or monthly) by an operator script. This is operationally cheap and makes the proposal numbers authentic enough to trust.
The demo opening replaces a single weekly-goal text input with two sliders:
As the visitor adjusts either slider, a feasibility readout updates in real time. The readout names constraints plainly without giving advice:
| Condition | Readout language |
|---|---|
| Seed < $25,000 | "Heads up: accounts under $25,000 are subject to the PDT rule — day trading requires a minimum $25,000 balance (FINRA Rule 4210). Swing strategies and weekly options are still available." |
| Return-on-capital ratio is very high (e.g., 100%+ annualized implied) | "That target implies a very high annualized return on your capital. Most professional strategies target 15–30% annually. Test this strategy to see what the historical win rate looks like." |
| Seed is high + goal is low + risk profile is conservative | "This profile (large capital, modest weekly target, low risk) looks more like a traditional income portfolio. Test this strategy — or explore lower-risk structures like covered calls or conservative credit spreads." |
| Seed is moderate + goal is high + visitor selects options | "Options strategies can reach this target, but the probability of hitting $[goal] per week rises with risk. Test this strategy to see the tradeoff." |
Key language rule: Every readout ends in "Test this strategy" or "See the historical data" — never "You should" or "We recommend." The product is a testing tool, not a financial advisor. Strategy steering happens through information, not advice.
The feasibility readout is purely informational and educational. Copy must be reviewed against the platform's existing legal/compliance posture before launch.
The demo offers a small, labeled ticker picker (3-5 instruments) rather than a single fixed ticker. Each ticker has a one-line explainer so a visitor who doesn't know what "SPX" means is not lost.
| Ticker | One-line explainer |
|---|---|
| SPX | S&P 500 Index — the 500 largest US companies. The most popular underlying for options income strategies. No shares, cash-settled. |
| SPY | S&P 500 ETF — tracks SPX. Shares can be bought or sold. Options are slightly different from SPX but behave similarly. |
| QQQ | Nasdaq-100 ETF — the 100 largest non-financial tech companies (Apple, Nvidia, Microsoft). Higher volatility than SPX. |
| IWM | Russell 2000 ETF — 2,000 smaller US companies. More volatile than SPX; used by traders who want higher premium potential. |
| AAPL | Apple Inc. — the most widely held stock in the US. Familiar to most visitors; a natural entry point for stock-level options. |
Recommendation: Launch with SPX, SPY, QQQ (3 tickers). Add IWM and AAPL in v2 if conversion data shows visitors are selecting non-index instruments. Starting with 3 keeps the picker low-friction; 5 starts to feel like a decision.
UX note: The picker should not look like a filter or a dropdown. It should look like a row of 3-5 labeled chips or cards — one click to select, immediately visible what each is. The one-line explainer appears on hover or directly below the chip. Selection is pre-set to SPX on load; visitor can change it before hitting "Find structures."
Three conversion postures were considered:
| Posture | Trigger | Risk |
|---|---|---|
| Soft — sticky banner | Persistent "Sign up free" CTA visible throughout | Low friction, low signal — appears before user has invested effort; reads as noise |
| Medium — moment-of-investment CTA | CTA fires at the exact moment of maximum investment (user has seen their proposal, clicked "Paper it," and is looking at the fill receipt) | Higher intent signal; feels earned not pushy |
| Hard — feature paywall | Demo lets you propose, but "view the ledger" or "see the win-rate detail" requires an account | Frustrates modal visitor; risks feeling bait-and-switch |
Recommendation: Medium, specifically at the paper-fill receipt step.
The precise moment: after the user clicks "Paper it" and sees the fill receipt (entry price, delta, premium received, max loss), surface a conversion overlay:
You just stacked a rack. Sign up free — and it won't disappear. [Create account] [Keep exploring the demo]
This fires once, at one moment. It is not a popup on page load, not a countdown timer, not a sticky bar pestering them. It respects the user's intelligence and pays off the "paper-first" brand promise: you proved something just now; save it.
Rank-ordered by intent signal strength:
When a demo user converts (clicks "Create account"), the handoff should feel like continuity, not a cold start:
The handoff copy on the conversion screen:
Your demo session was the preview. Your account is where the ledger starts. The weekly number you set ($[X]) is already saved. [Continue to account setup]
The "$19/mo locked-forever" Founders offer was retired (PR #463, 2026-04-28). The replacement (per epic #204) is a time-based engagement loop: Founders get 3 months of free paper trading on signup conversion, with additional time earnable via feedback and referrals.
The demo-to-signup path routes to the same standard account-creation flow every other user hits. There is no "demo user gets special pricing" bypass.
Once the 250-seat Founders cohort is filled:
Your account starts with full paper trading, free. Upgrade to Pro when you're ready to run a real book. [Create free account]
The demo's demo_founders_cta_variant feature flag controls this switch. When Founders seats are full, the flag flips to standard and no Founders copy appears anywhere in the demo flow.
The engagement loop's core mechanic is: free time earned through use (paper trading) + feedback + referrals. The demo is a taste of the first verb ("paper it") that motivates joining the loop. The conversion copy should land on the loop, not on a price:
Demo-to-Founders copy (while seats remain):
Founders get 3 months free. Paper trade as much as you want. Earn more time with feedback. No credit card until your window closes. [Join the Founders list]
This copy is loop-forward (time, feedback, no-card) not price-forward ($0/mo, free tier). The $0/mo framing during a free trial invites "well then why would I ever pay" — avoid it. "3 months free" is a duration offer, not a price promise.
Three SaaS products that handle open-flow demos well:
Notion — "duplicate this template / try with sample data" Steal: the "sample data" pattern — real-looking content in an ephemeral workspace, no login required. The visitor experiences the product's value prop (linked databases, block editor) without touching a blank slate. Apply to Raxx: the demo session starts with pre-seeded sliders (seed capital $25,000, goal $500/week) and a pre-selected ticker (SPX) so the visitor never faces an empty state. Skip: Notion's sample data is fully fake (lorem ipsum project boards). For a financial product, fake data that doesn't reflect real prices reads as unserious. Use real-but-frozen historical data instead.
Figma — interactive demo file (view-only) Steal: the distinction between "this is explorable but not saveable" and the pitch for what a real account adds. Figma's demo file shows multiplayer cursors that disappear unless you sign up. The visitor experiences the core product, then experiences a specific loss of capability that makes sign-up feel like gaining something, not paying to remove a restriction. Skip: Figma's demo requires creating an account even for view-only. For Raxx, the first 90 seconds should be zero-friction (no email, no passkey) — gate at the paper-fill step, not at the door.
Linear — project onboarding with a pre-loaded workspace Steal: Linear's new-account flow dumps you into a pre-configured workspace (sample project, sample issues, sample roadmap) so you see what a "good" Linear setup looks like before you've built anything. Apply to Raxx: the demo session should start with sliders pre-set to reasonable defaults — the visitor inherits a context, not a blank form. Skip: Linear's "sample workspace" is a template for the user's own data — it persists and eventually becomes cluttered. Demo sessions should not persist; clear the sample data when the session expires.
How it happens: The demo is too narrow — fixed ticker, no personalization — and visitors who trade anything other than SPX credit spreads never see themselves in it. Or the demo is too polished but too shallow: it looks like a marketing video, not a product, and visitors leave thinking "nice UI" without "I want this for my actual trades."
Mitigation: The demo must be interactive enough to feel real, which means the sliders must respond in real time (different seed capital + goal combinations produce different feasibility readouts and different proposal outputs). The ticker picker gives each visitor one more personalizing choice. Instrument the session token to capture slider positions, ticker selection, proposal click depth, and paper-fill completion rate. If paper-fill completion is below 60%, the flow is losing people before the conversion moment — diagnose immediately.
How it happens: If the demo is too capable and the session-expiry mechanic is easy to defeat (e.g., refresh the page to get a new 30-minute token), some visitors will cycle through demo sessions to run "free" proposals without ever signing up.
Mitigation: Rate-limit demo session creation by IP and/or browser fingerprint (PostHog's fingerprinting is already in the analytics stack per epic #204 — this is a natural extension). More than 3 demo sessions per IP per 24-hour window triggers a "you're getting value — here's a free account" prompt rather than a hard block. This turns abuse into a conversion signal. The Free tier's 25 AI proposals per month is already generous; a visitor who needs more than 3 demo sessions is exactly the user who should be on the Free tier.
How it happens: Pre-launch, Raxx's positioning could shift. If the backtesting lab ships ahead of schedule and becomes the stronger hook, or if the iron-condor screener turns out to be the viral feature, a demo hard-coded around the "weekly number → AI proposal → paper fill" loop is the wrong demo.
Mitigation: Build the demo as a configurable flow, not a hard-coded sequence. The underlying product surfaces (proposal engine, paper-fill endpoint) are the same ones the real app uses — the demo is just a restricted, pre-seeded version of the real app with an ephemeral session. If the product pivots, the demo pivots without a separate demo rebuild. Keep the demo's surface configuration (which tickers are in the picker, what the slider defaults are, which steps are visible) in a feature flag or a config file, not in hard-coded HTML.
Status: Pending business-legal-researcher analysis (in flight, parallel dispatch — 2026-04-29 UTC)
The question: what does an email-gated "continue session" flow look like that: - Is NOT email-list management (no newsletter, no marketing list) - Does NOT require running an identity provider (too costly at this stage) - Complies with anti-spam law (CAN-SPAM, GDPR Art. 6 legitimate interest vs. consent) - Complies with applicable privacy rules for storing a bare email address temporarily
The UX hypothesis: when a visitor reaches the backtesting surface (future — post-GA), a prompt fires: "Want to continue your session? Enter your email — we can't save your data until you register, but we'll hold your spot." This is a session-continuation mechanic, not a signup form.
business-legal-researcher is researching the regulatory surface of this mechanic. Once that analysis lands, the answer here will specify:
- What can legally be stored (email address, duration, purpose)
- What copy is required (opt-in language, data use disclosure)
- What the session-continuation UX is allowed to do vs. what requires full account creation
Do not file engineering cards for session continuation until this decision is resolved.
| Date (UTC) | Change |
|---|---|
| 2026-04-29 | v1 created (marketing-strategist) |
| 2026-04-29 | v2 — Decisions 1-4 resolved per Kristerpher's PR #465 review. Decision 5 pending BLR analysis. |