Can Lovable Build an MVP? Testing the Limits of AI-Assisted Development

Changing Direction: Build First, Market Later

I came into this session planning to start marketing the landing page. The conventional wisdom says spend 20% building, 40% on general marketing, and 40% talking to potential users. But after reflecting on the community feedback, I changed the plan.

The feedback was consistent: the before/after slider communicates the concept, but people want to see the data moving. Static numbers on a photo are a proof of concept. Dynamic telemetry synchronized with video is the product. Without that, marketing feels premature.

So instead of writing Reddit posts, I decided to spend two more sessions building a client-side demo — something that works directly in the browser, no backend needed, that visitors could try with their own YouTube links and GPX files.

The Pivot: From Viewer to Video Generator

During the week between episodes, a conversation with a developer friend crystallized something. The original product concept was about viewing — sync your video with GPS data and see it together. But the real value is creating — generate a 30-second vertical short with telemetry overlays baked in, ready to post on Instagram, TikTok, or YouTube Shorts.

This shifts the technical architecture significantly. Viewing is client-side JavaScript. Creating is server-side video processing — downloading the video, rendering overlays frame by frame, cutting clips, and outputting a new video file. My friend estimated 7-10 days of focused work for the rendering pipeline.

But the client-side demo is still valuable. If someone can see their own data overlaid on their own video in the browser, even without the ability to export, they'll understand the product instantly. That's the demo I'm building today.

The Tool Debate: Lovable vs Cline vs Cursor

A community member named Shanier left a comment that sent me down a rabbit hole. He suggested using Cline — a VS Code extension — with Google's Gemini API instead of Cursor or Lovable.

The insight was about economics. Lovable, Cursor, and Windsurf are all wrappers around large language models. You pay a subscription, and they manage the API calls. But at some point, to make the subscription profitable, they have to limit you — fewer context tokens, model downgrades during peak hours, or request caps.

Cline lets you plug in your own API key directly. You pay per token consumed, not per month. Google gives approximately $300 in free Gemini credits to start. For our use case, that's potentially months of development without spending anything.

I also discovered Addy Osmani's newsletter — he's a Google engineering manager who wrote extensively about why he prefers Cline. His argument resonated: when you control the API connection, you control the quality ceiling.

For now, I'm sticking with Lovable for this demo because I want to test its limits on actual application logic, not just landing pages. But the shift to Cline for the real MVP development is planned.

Building the Demo: From Prompt to Working App in 30 Minutes

I took the implementation prompt that Claude had generated — a detailed specification for a client-side GPS-video synchronization tool — and fed it directly to Lovable.

What Lovable produced in the first pass:

A multi-step wizard with four stages: load a YouTube video, upload a GPX file, synchronize a point in the video with a point on the GPS track, and view the result with telemetry overlays.

The GPX parser was remarkably complete. It correctly extracted latitude, longitude, elevation, time, heart rate, cadence, speed, and power from the file. It calculated aggregate statistics — total distance, elevation gain, average speed. It even included the Haversine formula for calculating distances between GPS coordinates, complete with the Earth's radius constant.

The route map rendered correctly using Leaflet, showing the full GPS track with a movable marker. The YouTube player embedded properly with time controls. The telemetry overlay appeared over the video with the correct data fields.

The 80% that worked: Navigation between steps, GPX parsing, map rendering, YouTube embedding, basic overlay display, data persistence between steps (using local storage), mobile layout.

The 20% that didn't: Real-time telemetry updates during video playback. The overlay showed the data from the synchronization point but wouldn't update as the video played. This is the core feature — and it's the one that didn't work.

Why the Last 20% Is the Hardest

The synchronization between video playback time and GPS track position requires a tight feedback loop: every frame (or at least every second), read the current video timestamp, calculate which GPS point corresponds to that timestamp based on the sync point, and update the overlay numbers.

Lovable understood the concept. The code it generated had the right hooks, the right state management, the right event listeners. But something in the execution — possibly a React lifecycle issue, possibly a timing conflict with the YouTube iframe API — prevented the real-time updates from firing.

I spent 30 minutes debugging with Lovable, asking it to examine the time tracking mechanism, refactor the playback component, and check the interaction between the sync context and the video player. Each iteration got closer but never crossed the finish line.

This is the pattern with AI-assisted development: the architecture is sound, the code structure is clean, the individual pieces work — but the integration between real-time browser APIs (video playback events) and React state management has edge cases that require human debugging.

Kling AI: A Glimpse of the Future

While waiting for Lovable to process changes, I tested Kling AI — a tool that generates short videos from a single image. I uploaded the cycling photo with the Photoshop overlay and asked it to animate the cyclist pedaling down the road.

The result was surreal. It generated a 5-second clip of a cyclist riding down a sunlit road — not my actual road, but convincingly realistic. The trees moved, the perspective shifted, the cyclist's legs pedaled. It wasn't my footage, but it demonstrated something: AI video generation is close enough to produce marketing content, if not actual product demos.

For SportsSync's purposes, though, real footage with real data is non-negotiable. The whole product is about authenticity — your actual ride, your actual heart rate, your actual speed. Synthetic video undermines the core value proposition.

What I Learned About AI Development Tools

After six episodes of building with AI tools, some patterns are clear:

Lovable excels at: Landing pages, form handling, database connections, basic CRUD, static layouts, mobile responsiveness, component-based UI.

Lovable struggles with: Real-time synchronization, complex state management across multiple data sources, debugging integration issues between third-party APIs, performance optimization.

The 80/20 rule applies literally. AI tools get you 80% of the way in 20% of the time. The remaining 20% takes the other 80% — and often requires dropping down to manual code editing. This isn't a failure of the tools. It's the nature of software: the last mile is always the hardest.

Next Steps

The client-side demo is 80% functional. The telemetry overlay exists, the synchronization mechanism is built, the data flows correctly through the system. What's missing is the real-time update loop during video playback — a specific, debuggable problem that I'll solve either in Lovable or by moving the code to VS Code with Cline.

Once the demo works, the plan is:

1. Show it to two real cyclists I know — Edu (my training coach) and Marc (a cycling content creator)
2. Get their honest feedback on whether this is something they'd use
3. Based on that feedback, start building the server-side video rendering pipeline

We're closer than I expected. The product isn't done, but the shape of it is clear.