Implementation & Product Spec

The foundation worked out before any build: what each feature is, exactly how it runs live, which real provider powers it, what we reuse vs build, the design direction, and the decisions that gate everything. Grounded in the actual code (fe-main, main monorepo, justsext-landers), the live ElevenLabs config, Linear, and Slack — not the prototype.

0TL;DR & verdict

Lure can be built almost entirely from systems that already exist in production. The lander lives in justsext-landers and reuses its attribution, Google auth, and analytics verbatim. The live voice call is the same ElevenLabs path the product runs today. Demo photos are served by a live endpoint from galleries that already exist for Sophie Dee. The work is mostly assembly + a new demo agent + a real design, not greenfield.

Three things are not ready and gate the monetizing parts:

Everything below treats those as decision points with options + a recommendation, so the spec is actionable now.

1What the brief got wrong (now corrected)

2Architecture & data flow

One sentence: a Next.js lander on landers.justsext.com runs a live ElevenLabs voice call through the existing voice backend, gates the user, registers them with the same Google auth as the app, charges them through the live gateway, then hands off into the SIREN product via a one-time exchange code.

Throughout: every funnel step fires an event carrying affid + ef_transaction_id + creator_id (GTM-2182), aligned to the C78 dictionary, joined on call_id.

3Feature spec — live, per feature

For each feature: how it works for real, the provider, what we reuse, what we build.

3.1 Live voice call build (port)

Not a mock. The browser holds a real WebRTC/WebSocket session with ElevenLabs Conversational AI.

• Transport: @elevenlabs/client Conversation SDK (v1.2.0, same as the product). The lander is React, so re-implement the pattern from fe-main/src/app/shared/services/elevenlabs-call-provider.service.ts (it is Angular; lift the logic, not the file).
• Session start: GET call.app.justsext.com/calls/signed-url?creator_id=<id> with a Bearer JWT → returns signed_url, agent_id, call_id, max_duration_seconds. This call is the "call started" signal and starts billing server-side.
• Dynamic variables: pass call_id (+ creator_name) via conversation_initiation_client_data. Add user_account_id once D2C-5065 lands. The post-call webhook reads these back.
• State signals (free): onModeChange({mode:'speaking'|'listening'}) + a volume RAF loop. These drive the speaking animation and (later) the avatar with no extra work.
• Duration cap: server computes max_duration_seconds from wallet balance and the SDK enforces it. For the demo, the cap is the agent-level setting on the new lander agent (see decisions).

3.2 The demo voice agent blocked on Karen duration value

A new ElevenLabs agent, sophie-dee-voice-lander, cloned from Sophie Dee - Web (agent_9601kph9vs55ek4b08nj4bv86v03).

• Why new, not a branch: max call duration is agent-level, and the live agent's override whitelist blocks prompt / first_message. To set a short demo cap and inject the oversell opener, a dedicated agent is required. Decided in Slack; needs Karen to create it with overrides + conversation_initiation_client_data enabled.
• Inherits (copy from Sophie-Web): the staged Warmup→Build→Escalate prompt, voice caFdfEzBHwcRadC1N5k0 on eleven_v3_conversational, LLM gpt-5.1, the 6 RAG scenario cards (the engagement engine), and the 4 eval criteria (engaged_call, reached_escalation, cta_delivered, no_premature_end).
• Differs: shorter max_duration_seconds (the demo length), an oversell-tuned prompt (faster "holy shit" in 30s), and CTA copy pointing at register/paywall instead of the in-app photo button.

3.3 The 7 gamified mechanics build (UI) density

Client-side state on top of the live call. Each maps to an in-product SIREN ticket so the behavior is defined, not invented. Put every mechanic behind a Statsig flag so the active set is config, not a deploy (GTM-2179 / GTM-2186).

Photos are not generated live. The "just generated" framing is a UI illusion over pre-gen assets (see §5). The slot-machine spin spec (1.4s, cubic-bezier, unlock at 12 tokens, heat math) is fully written in D2C-4624 — copy it.

3.4 Registration — same Google auth as the app reuse

• Mechanism: AWS Cognito Hosted UI (Google as IdP) → POST api.justsext.com/auth/auth/google {code} → backend exchanges at Cognito, mints STXT access+refresh JWTs (claim stxt_user_id). Identity is keyed on the Cognito sub, so the lander account is the app account.
• Reuse: justsext-landers/lib/auth.ts (googleAuth, buildGoogleOAuthUrl, signup) + app/auth/callback/page.tsx already implement this. Guest→user upgrade is automatic when the guest token is passed.
• Needs: real Cognito env values (placeholders today) and the lander callback URL added to the backend GOOGLE_LOGIN_REDIRECT_URLS_ADDITIONAL allow-list, or /auth/google rejects it.

3.5 Hard paywall blocked: payment broken

• Live gateway today: OpenPay. Saved payment_method_id on openpay_customer_id enables a one-click "no re-auth" charge → webhook credits tokens_balance.
• Reality: gateway is OpenPay (confirmed). The open item is that the prod checkout broke Jun 23 — confirm it is fixed before paywall work. No Centrobill dependency.
• "Buy first, register after" (the friction-killer A/B) is not built — the purchase route requires an authenticated user. Needs eng scoping before it can be promised.

3.6 Live avatar vendor M3

Two genuinely different paths. The call screen already exposes the attach point: swap the single creator <img> for a <video> driven by the existing isCreatorSpeaking + volume signals.

• Pre-rendered looping clips (recommended first): generate 1-2 short clips per creator with fal.ai (Kling Avatar v2 Pro / OmniHuman) — idle loop + active-while-speaking loop. Cheap, no per-call cost, no latency risk, full NSFW/likeness control. This is what both tickets (D2C-5033, GTM-2184) actually lock to.
• Real-time lip-synced avatar: ElevenLabs has no native realtime avatar. EL "LiveAvatar" is powered by HeyGen, which bans explicit content — bad fit. Anam (CARA-3, ~180ms) and d-id ($5.90/min) are options but NSFW tolerance is unverified. d-id + Rogue AI vendor meetings were the week of Jun 22 (outcome pending).
• Hard gate either way: Sophie Dee likeness/consent sign-off (Erin/legal) before generating any motion video.

3.7 Handoff into SIREN reuse

After purchase, mint a 30-second one-time code (POST /auth/auth/exchange-code/create, Bearer user token) and redirect to justsext.com/?exchange_code=…&creatorId=…&startCall=true. The app auto-redeems and starts the live sophie-dee-web call. Backend is ready; standardize on this (not the ?code= hack currently in the landers repo, which is a latent bug).

3.8 Instrumentation build to spec

Events fire at every step (lander_view → demo_call_started → demo_chip_tap / emoji_react / photo_spin / photo_unlock / heat_milestone → demo_gate_reached → demo_registration_completed → demo_paywall_view → demo_purchase), each carrying affid + ef_transaction_id + creator_id, joined on call_id, aligned to the C78 dictionary. Owner: Mac, under Ilia (GTM-2182). Reuse the lander's existing Segment/GTM/PostHog rigs.

4Provider & systems map

5Content strategy — video-first on Sophie Dee

Creator: Sophie Dee. She is the one we test everything on, has the most ready content, the live EL agent, and a complete tagged gallery. Lock her as the launch creator (Eric's Jun 21 DM steer: pick 1-2 creators, move fast; pre-gen and live-gen both available).

Medium: go straight to video, skip photo-only testing. Ilia's call — video is more engaging than stills, so the demo content (the "slot machine" reveal, the creator hero, the escalation arc) should be short video clips, not photos. The photo-unlock mechanic stays as a shape, but what it reveals is video.

Two axes we test (both, not either/or)

• Non-live (pre-generated) video — generate a curated set of short Sophie clips up front (idle loop + escalation reveals), serve from CDN. Cheap, full quality/likeness/NSFW control, zero latency. This is the safe baseline to ship first.
• Live (real-time generated) video — generate/stream reactive video during the call. Higher fidelity of "she's really here," but cost + latency + content-policy risk. Test against non-live to see if the lift justifies it.

What we reuse vs generate

• Pipeline exists: per-creator LoRAs (fal.ai Z-Image for stills; fal.ai Kling / OmniHuman for image-to-video) → assets stored in Mongo medias with escalation_step (1 sfw → 4 revealing/paywall → 5 nsfw), served via CloudFront / static.justsext.com. Sophie already has ~250 tagged stills to source frames/clips from.
• Reuse Sophie's existing content for the first non-live set, and generate new video (clips + avatar loops) where we need motion. Both are in scope.
• Pre-register (cold/anonymous): hard-coded curated clip set for Sophie, steps 1→4, no backend dependency. Post-register: optionally pull live from POST /medias/internal/free-media.

Hard gate: Sophie Dee likeness/consent sign-off (Erin/legal) before generating motion video. Confirm before any gen run.

6Design — rebuild from scratch, many variants

The current prototype is a throwaway placeholder. We rebuild the design from scratch and work it properly. But the engagement ideas stay — the whole point is to actively hook the user, so every mechanic and idea in the prototype is kept and tested, not thrown out. The redesign is not "remove gamification." It is two things: (1) raise the craft so every screen is clean, clear, and high-quality, and (2) produce many variants to test, because we don't yet know which shape converts cold traffic.

The variant matrix — we test across both axes

Plan for iterations, not one design. Two axes, and we build options along each:

Non-negotiable craft bar (applies to every variant, casino or clean)

1. Clean & clear. Whatever the density, the screen must read instantly — clear hierarchy, one obvious primary action, nothing confusing. "Casino" must still be a well-designed casino, not clutter.
2. Believable. It should feel like a real person on a real call (her real photo/video as the hero), not a generic AI widget.
3. Mobile-native motion. Sub-200ms feedback, physical iOS-grade easing. Cold paid traffic is mobile (Canada + Android convert best); design and test mobile-first; consider PWA if it buys smoother motion.
4. Conversion-UX baseline (from the brief): never a dead end; reduce choices at the paywall; never lock the action chips at the wall.

Quality is the constant; style and density are the variables. The visual system should be derivable from the creator's brand, and we should ship several iterations so the team can tap through and the live A/B can read which shape wins.

7Reuse map — what to lift, exactly

8Open decisions (with recommendations)

Each needs an owner sign-off. Recommendations are mine (Eric gave full latitude on Lure); the blockers need eng/EL confirmation.

9Risks & blockers

10Build sequence

11Immediate next actions

1. Sync with Ruslan — pull his GTM-2177 shell before any build. (I can draft the message; won't send without you.)
2. Confirm payment with Klemen/Eric — which gateway processes a Lure buy, is one-click no-re-auth available, and is the Jun-23 prod failure fixed? This gates the paywall.
3. Ask Karen to create sophie-dee-voice-lander with overrides + initiation enabled, and lock the max-duration value (rec 120s) in GTM-2178/2240.
4. Get prod secrets — Cognito domain/client-id + Segment write key; add the lander callback to GOOGLE_LOGIN_REDIRECT_URLS_ADDITIONAL.
5. Pick the demo creator + curate photos — Sophie Dee (matches the live agent + has the gallery); pull steps 1→4 URLs from the image-tags CSV.
6. Approve the design direction — give me the go to produce 2-3 redesign directions in the lander stack.