How Statly turns messy basketball data into coach-ready reports

#showdev #ai

Hello everyone - I'm building Statly, a basketball analytics product for coaches and scouts.

The biggest problem I kept running into was not the UI. It was the data.

Basketball sources do not all speak the same language:

team and player names do not always match
live and finished games need different logic
boxscore, play-by-play, shot charts, and game flow data arrive in different shapes
one brittle parser can break the whole report pipeline

So the core of Statly is not just report rendering. It is the pipeline behind it.

What we built

a scraper layer that collects game data from supported sources
a normalization layer that maps raw provider payloads into one shared report model
backend-owned report generation for coach-ready PDFs
cache-backed PDF delivery so repeated reports do not re-render unnecessarily
live and post-game support in the same pipeline, with lifecycle-aware report logic

The renderer should not care which provider the data came from.

If the normalized model is wrong, the PDF is wrong no matter how polished the frontend looks.

That is why we keep the source-specific logic in the backend and normalize everything before rendering.

For coaches and scouts, the goal is simple: explain why a game was won or lost.

That means the product has to be:

A pretty dashboard is not enough if the underlying report breaks when the source changes shape.

expanding league coverage
improving report quality and consistency
making the workflow easier for coaches, scouts, and clubs
keeping the product focused on basketball decision support, not generic AI branding

If you're building with messy sports data, I'd love to hear how you handle scraping, normalization, and report generation.