When Two YouTube Players Can't Coexist: Rethinking the Product Architecture

The Problem: Two Players, One Page

My plan was elegant: the landing page would have two instances of the telemetry player. The top one auto-plays a pre-configured demo with my cycling footage. Below it, visitors could paste their own YouTube link, upload their GPX file, and see their own data overlaid. Same component, two instances, one page.

It didn't work. After burning through dozens of Lovable tokens across multiple attempts, I discovered that having two YouTube iframe players on the same page creates conflicts. The players interfere with each other — one initializes correctly while the other fails to load, or both load but the synchronization logic gets confused about which player it's controlling.

I couldn't determine whether this is a fundamental limitation of YouTube's iframe API or a bug in how the code manages player instances. What I know is: I tried six different approaches over several hours, and none produced a reliable two-player experience.

The Better Architecture

The constraint forced a better design. Instead of cramming everything onto the landing page, I separated the experiences:

Landing page: The auto-playing demo stays. One player, pre-configured, showing the overlay in action. Below it, a prominent CTA: "Try it now" — linking to a separate page.

Demo page (/try-it-now): A clean, dedicated page where visitors upload their YouTube link and GPX file, synchronize, and see the result. No marketing copy competing for attention. Just the tool.

This separation has a hidden benefit: the demo page is architecturally identical to what the private dashboard will be. When we add user authentication later, the demo page becomes the logged-in experience. Same components, same layout, just behind a login wall with data persistence.

The Funnel Strategy

This connects to a marketing concept I picked up from Marc Lou: give away a small piece of the product for free, outside the main app. He does this with a free logo generator that funnels users to his full design platform.

For SportsSync, the funnel would be:

1. Speed Overlay (free tool, separate domain) — paste a YouTube link, upload GPX, see the overlay. No account needed. No data saved.
2. SportsSync (the product) — save your activities, generate downloadable shorts with overlays baked in, share to social media.

The free tool demonstrates value. The paid product delivers it permanently. The conversion happens when someone thinks "I want to keep this" or "I want to share this on Instagram."

AI-Powered Highlight Detection: It Works

I tested something exciting: uploading a GPX file to Claude and asking it to identify the most interesting moments of the ride.

Despite the file size limitations (GPX is verbose XML — the useful data is maybe 20% of the file size, the rest is tags), Claude successfully analyzed the telemetry and identified segments with high power output, fast descents, and interesting elevation changes.

This becomes a core product feature. Instead of making users scrub through a two-hour ride to find the exciting 30 seconds, the AI suggests highlights: "Here's your fastest descent," "Here's where you sustained 300 watts for two minutes," "Here's the steepest climb." Like Opus Clip for podcasts, but for cycling telemetry.

The implementation path is clear: parse the GPX server-side, send the data points to an LLM, get back timestamp ranges with descriptions, and present them as suggested clips.

Google Analytics: Proving There's an Audience

Analytics has been running for a few days and shows real traffic beyond my own visits. Visitors from Spain (expected), Argentina, Colombia, and — curiously — Germany. Most traffic correlates with YouTube episode releases, but there's some organic discovery happening.

The data isn't actionable yet (too small a sample), but it confirms the landing page is reachable and people are finding it through the YouTube series. Once we start actual marketing, these numbers become the baseline.

Lovable's Pricing Reality

Lovable changed their pricing: the €20 and €50 tiers are gone. It's now free or €80/month. For the landing page work, the investment was justified. But at €80/month for an AI development tool with token limits, the economics don't work for ongoing development.

The plan was always to transition to a proper development environment for the backend. This pricing change accelerates that transition. VS Code with Cline, direct API access, and full code control is the next chapter.

Community Wisdom: Working With AI More Effectively

Three insights from community comments that changed how I work with Lovable:

David's tip: When TypeScript errors appear, click "try to fix" — it doesn't consume message credits. The static type checking iterations are free, and Lovable will keep fixing until the types are clean.

Gilberto's suggestion: Use Gemini for context-heavy tasks. Its million-token context window means you can feed it an entire codebase and ask questions without hitting limits. Then take Gemini's analysis to Claude for implementation.

Julio César's approach: Maintain a running memory summary that you paste into new chat sessions. When the AI loses context (which happens in long conversations), you have a pre-written brief that catches it up instantly.

What's Next: Three Tracks

The landing page phase is closing. What follows runs on three parallel tracks:

Backend (Episode 11): A brainstorming session with a backend developer friend from India. The architecture: download YouTube video → cut clips → render telemetry overlay → composite → output shareable video. His estimate: 7-10 working days. The session will be in English with Spanish subtitles.

User Research (Episode 12): Prepare a research script with Claude, then two 15-minute conversations with real cyclists. Not selling — listening. What do they actually want? Would they pay? What's missing?

Marketing (Episode 13): Define a strategy with Claude's help. Organic content, SEO, potential paid campaigns. Plus an experiment: automating YouTube-to-Twitter content repurposing with N8N.

The building continues, but the direction is no longer mine to decide alone. Real users get the next vote.