About Illustrated Stats

Built for real teams, not demo theater.

This app exists to make basketball tracking usable on real nights with real parents, coaches, helpers, and season history that actually matters later.

Open Teams How It Works Try Me
Why It Exists Paper stats, scattered spreadsheets, and chaotic bench workflows were not good enough.
Who It Serves Coaches first, parents naturally, and organizations that want repeatable structure.
What Matters Fast game-night flow, durable history, and shared control without losing quality.
Explore The App Short sections. Open the ones you care about.
Why Who It Is For Product Shape Quality Bar What Is Next
Why This App Exists Because live stats should not require a clipboard cult and three side chats.

Illustrated Stats was built for the actual mess of team life: multiple adults, fast games, uncertain helpers, and the need to keep a season coherent without office-grade overhead.

The goal is simple: make the useful path obvious enough that people use the app instead of avoiding it.

Who It Is For Different audiences, one product, one consistent workflow.
Coaches Need control, approvals, clean game records, and season history that holds up.
Parents Need something simple enough to use on the phone without turning the game into IT support.
Organizations Need repeatable structure, shared standards, and data they can trust later.
Players Benefit when the adults around them finally keep records in one coherent place.
What Is Next The app now works. The next phase is making the system behind it just as strong.
Theme System Controller Decomposition Shared Components Team Themes

The product now has a clear UI system. The next work is about making the internals lighter, cleaner, and easier to evolve without re-breaking good pages.

What The Product Actually Does Teams, seasons, live tracking, approvals, exports, and long-term player history.
Teams Seasons Lobby Enter Stats Exports Reports

This is not just a scoreboard. It is a team workflow with records that survive beyond tonight’s game.

Quality Bar The visual system and the code structure both need to earn trust.

The app already became much better-looking and more usable. The current work is about making the backend structure, theming, and shared components worthy of that finished product surface.

Translation: fewer giant controllers, fewer hardcoded styles, more reusable pieces, and less pain every time you want to change the product.
How To Read The App Think in layers: tokens, shared elements, page surfaces, then behavior.
Tokens Color, spacing, surfaces, borders, type emphasis, and theme behavior.
Shared Elements Cards, pills, toggles, drawers, promo bands, and mobile menus.

That is the model you want when you ask for changes later: change the right layer once, not six pages separately.