Video Highlights with GPS Overlay

FiyrPod already had rich GPS session data: speed peaks, acceleration bursts, and distance covered. Video of the same sessions existed too, but in a different place. Coaches were reviewing analytics in one screen and video in another, asking athletes to mentally connect the two.

I realized early that analytics and shareability were not separate goals. The social layer was the growth engine. If athletes could export the exact moments their speed peaked, the product would stop being an internal tool and start becoming public proof of what FiyrPod could do.

The product captured value internally, but it had no mechanism to amplify that value outside the app. Athletes and coaches had no smooth way to turn tracked performance into content they could actually post.

I looked at what athletes were already sharing on Instagram from FiyrPod. More than 80 percent of posts were speed clips. Not readiness. Not load charts. Speed. That behavior made the product direction obvious before a single screen was designed.

I looked directly at what athletes were already sharing on Instagram from FiyrPod. That gave me the answer the product needed: athletes were using speed as the story. The feature had to be built around that behavior instead of around every metric the platform was capable of displaying.

That same principle shaped the export path. A share flow should preserve momentum, not interrupt it. Every extra setting between seeing a great moment and posting it was a chance to kill the behavior the feature was supposed to unlock.

The first version required users to manually attach a GPS session to a video and adjust alignment if the sync felt off. It did not feel off. It was often wrong. Incorrect session selection and timestamp mismatches created overlays that showed peak speeds at the wrong moments, which destroyed trust quickly.

Engineers identified that video file metadata and GPS session start times could be matched automatically. My design decision was insisting that this become the default experience rather than an optional helper. The manual override stayed for edge cases, but 99 percent of users no longer had to encounter the alignment problem at all.

The product already tracked far more than speed, and the natural temptation was to prove that richness in the overlay. I pushed in the opposite direction. Athletes were not looking for a portable analytics dashboard. They were looking for a brag-worthy moment.

That decision was grounded in direct behavior. More than 80 percent of the athlete posts I reviewed were speed-focused. Shipping a single, highly legible metric on top of the video created a better share object than adding every available data point and making the export harder to read.

The original export flow had five steps: select clip range, choose metrics, toggle branding, preview, then confirm. Testing showed a clear pattern. Users who reached preview exported successfully, but too many never got there because the configuration overhead killed the impulse to share.

The shipped version treated defaults as product strategy. Clip range auto-selected around the peak speed moment. Branding stayed on. Speed remained the only visible metric. The default path became one confirmation instead of a reporting workflow.

In internal testing, none of the three testers completed the original flow end to end. All three completed the shipped flow without abandoning it once. The options stayed available, but they were no longer the main path.

After launch, the feature became one of FiyrPod's strongest organic distribution loops. Out of 22 recent Instagram posts, 15 featured speed-highlighted video exports from this feature. Average views per video reached 28K, with a peak video at 236K views.

Auto-sync accuracy reached 99 percent, eliminating the main trust failure from the original flow. Satisfaction landed at 9 out of 10 across coaches and athletes, and the feature became the number one requested extension for the Athlete app.

After launch in the Coach app, athletes began asking for the same feature in the Athlete app. Instead of waiting on an engineering sprint, I shipped it myself using Claude Code and Cursor to direct AI-assisted development.

The code was mostly AI-generated. The product decisions, prompts, review criteria, testing, and quality bar were mine. That work removed an engineering dependency for a feature users had already demonstrated they wanted.

The speed-only constraint in version one was the right call, but now the product has behavior data from real exported videos. Which moments athletes choose to highlight, which sessions they share, and which speed thresholds they feature all create a much stronger basis for deciding what metric comes next.

I would build the next version of metric selection from that behavioral signal, not from assumptions about what coaches or the team think athletes want to show off.