Gamecast: Building an Athlete Layer for Live Sports Video
Combined AI computer vision and live scoring data to build a video feed that follows the athlete, not just the team.
AI product design
0-to-1
Systems-Thinking
Role
Lead Product Designer
Team:
Product, Dev
Tools:
V0, Claude, Figma
Timeline:
7 months Sept ‘25-April ‘26
THE PROBLEM
Parents come here to watch videos of their kid but we only had the concept of teams.
SportsEngine’s video product had no concept of an athlete, so millions of parents already rostered on a SportsEngine team with no easy way to find content of their kid.
THE APPROACH
Launched an MVP to see what real data from AI tracking looks like
Shipped a scrappy V1 on jersey numbers alone, no accounts yet, to get real computer vision data flowing before solving who any of it belonged to.
THE FINDINGS
Live sports data is messier than what we predicted
The beta surfaced accuracy problems and mistagged players immediately, reshaping how we thought about trust in the gamecast feed.
THE OUTCOME
Shipped, iterating, and in active expansion
GameCast is live with a real customers connected to in-season rosters. I handed off ownership as that phase began but the team is currently working on next iterations.
THE PROBLEM
SportsEngine is the platform millions of youth and rec sports families already run their season through, registration, scheduling, communication, rosters. SportsEngine Play is our video product living inside that same ecosystem.
The problem is we knew our athletes everywhere except video. Parents were already rostered on a SportsEngine team, often already paying for the ecosystem, and our video product just didn’t know their kid existed. It only understood teams and games. So there was no real reason for that huge existing audience to ever open it looking for their own kid’s moments.
CORE INSIGHT
Millions of parents were already inside our ecosystem, with no emotional incentive to engage in video.
WHY NOW —
A few unrelated bets we’d already made suddenly added up to something new.
A few things came together around the same time, mostly by coincidence more than grand strategy. AI camera tracking finally got good enough to identify players and plays on its own. We’d just shipped a mobile scoring tool for live events. Our Scorebird integrations had gotten more reliable.
None of it was built with this project in mind, but put together, we suddenly had real signal about what was actually happening in a game, tied to a specific moments. It was the perfect opening
SOURCE 1
AI Camera Tracking
Automated jersey ID through Computervision
SOURCE 2
Live Scoring data
Manual scorer entries through our mobile app
SOURCE 3
Scorebird Integrations
Scoring partners that record updates from the scoreboard
A holistic play-by-play feed
A holistic view of what is happening in the game, one a viewer can trust
THE DESIGN —
Meet Gamecast: Athlete moments alongside the game.
Here’s what a parent actually sees. The live video sits on one side, and a real-time play-by-play feed runs alongside it, filterable down to a single player. Jersey number and name are the headline of every entry, not the stat line. Play context is there, but it’s supporting detail, not the main event, because a busy parent isn’t scanning for a box score, they’re scanning for their kid.
THE PROBLEM —
We started with an MVP, to start seeing what the real data looked like.
Two problems stood between us and something useful.
The first was noise. We had three different data sources, each with its own reliability, its own latency, its own emotional weight, and all of it needed to collapse into one feed a parent could trust without drowning them in every little thing that happened on the court.
The second, and honestly the harder one, was identity. Knowing that number nine scored at the six-minute mark doesn’t mean much if you can’t connect that to an actual person’s SportsEngine account. We had no way to make that link.
We couldn’t solve the identity problem in a whiteboard session, so we didn’t try to. We built a V1 that ran on jersey numbers alone, no accounts attached yet, just to get real computer vision data flowing through the product and see what we were actually dealing with. Turns out that’s a very different problem than concepting it on paper. Watching a model try to track a jersey number through an actual chaotic basketball game taught us more in a week than any prototype could have.
REAL DATA, REAL FEEDBACK —
We turned QA into a team field trip, powered by Codex.
We launched the GameCast beta with one basketball tournament customer, and the feedback started rolling in almost immediately. Players tagged with the wrong number, moments attributed to someone who wasn’t even in the play. Not exactly shocking given how early the model still was, but it made one thing clear: we needed a real way to catch this stuff at scale, not just react to complaints as they came in.
So I worked with my PM to build one. We called it the Pixellot Highlight Review Field Trip, half real process, half fun team activity. Anyone on the team could load a review skill into Codex, pull up a game’s Player Reels, and just watch, dictating notes out loud as they went: mistagged players, wrong jersey numbers, reels built around a play that never actually happened. Codex took those notes and formatted them into rows tied back to the correct reel, ready to drop into a shared tracking sheet for the model team to work from. We even used it to flag the genuinely great reels worth holding onto for marketing later.
It turned what could have been a tedious manual QA slog into something closer to a scavenger hunt, and it’s still how the team catches accuracy issues today.
WHERE IT STANDS —
Next up: Turning jersey numbers into real athlete profiles
Jersey numbers got us a working feed, but they were always meant to be a starting point, not the destination. The real plan is connecting GameCast to actual SportsEngine Play rosters, so every tagged moment ties back to a real athlete account instead of just a number on a jersey.
That work is underway now: linking rosters to real teams, pulling player data in from the team channel and video feed, matching players to their moments, and notifying parents the second their kid gets tagged. Once an account is behind the data instead of just a jersey number, the product opens up. An athlete stops being a moment in one game and becomes a profile you can actually follow.
REFLECTION —
WHAT I’D DO DIFFERENTLY
Planning more for the future state of connecting accounts
If I could go back, I’d pull the identity work forward instead of treating it like a clean second phase. Roster connection and notifications ended up being just as involved as the original feed problem, and starting that groundwork earlier, even alongside the V1 build, probably would have saved some rework once real accounts entered the picture.
WHAT THIS PROJECT REINFORCED
You can’t design around real AI data
The jersey-only V1 only mattered because it forced the actual mess, the mistagging, the low confidence, the weird edge cases, out into the open early, and no amount of prototyping was going to show us that on its own. If a feature depends on a model that hasn’t seen real-world input yet, get real input in front of it as fast as you can, even if the rest of the product isn’t ready.