An AI scouting department for a Little League team

I'm an assistant coach on my son's AAA Little League team, the Alameda Aces. Every team in our league scores its games in GameChanger, which means every game produces a beautiful pile of data — box scores, play-by-play, pitch counts — that mostly goes unused. Coaches check their own team's batting averages, and that's about it.

Meanwhile, the questions we actually argue about in the dugout are scouting questions: What's this pitcher's walk rate late in games? Does that team steal on the catcher? Who should bat cleanup on Tuesday? The data to answer them exists. Nobody has time to dig it out at 5pm on a school night.

So I built Scout: a mobile-first app with a stats explorer, pushed scouting insights about your next opponent, a drag-and-drop lineup builder, and an AI agent (also named Scout) you can ask anything — backed by real play-by-play from every game in the league.

Product thinking: built for the night before the game

A few decisions came before any code:

• Scout is a prep tool, not an in-game crutch. Nobody wants coaches staring at phones during a Little League game. Scout's job is to help the staff walk in with a plan — lineup set, pitching aligned, the opponent's tendencies already in mind. It saw some in-game use, but the real win was solidifying the game plan beforehand.
• The user is a volunteer coach on a phone. Not an analyst at a laptop. Mobile-first with no desktop version at all, an iOS-app feel rather than "website that happens to work on a phone," and answers that lead with the verdict — a coach filling out a lineup card doesn't want the methodology first.
• Insights are pushed, not pulled. The home screen tells you about your next opponent without being asked — and only surfaces things you genuinely can't get from a box score, like "17 of their 61 runs score in the 4th inning." Each insight is color-coded green, yellow, or red: things we can attack, things to watch, things to avoid.
• Meet coaches where their eyes already are. The stats table deliberately mirrors GameChanger's layout — pinned player column, horizontally scrolling stats, alternating row shading, tabular numerals — because every coach in the league already reads that format fluently. Familiarity was a feature.
• Kids' privacy is a hard constraint. Every player, everywhere — UI, data files, AI responses — is "First L., #2" format, never full last names. It's enforced in the data pipeline and written into the agent's system prompt.

The data problem: there is no API

Here's what almost killed the project on day one: as a coach I can export my own team's stats. The other nine teams' coaches don't share theirs, and GameChanger has no public API.

But box score and play-by-play pages are viewable. So the pipeline became: screenshot every box score in the league (160+ screenshots) → Claude Chat extracts each one into structured markdown, validated against team totals → Claude Code parses the markdown into JSON at build time — every plate appearance with inning, runners, result, and pitcher. Later I turned the capture step into a reusable Claude Code skill: after each new game, Claude drives a browser to the GameChanger page, extracts everything, cross-checks the totals, and files a clean record. New game to updated app in minutes.

The unglamorous truth is that data quality was the hardest ongoing work. Claude Chat caught transcription errors by diffing against my official export. A validation script caught a parser bug that had silently dropped eight Iron Birds games (a case-sensitive header, naturally). A coach who catches one wrong batting average stops trusting every number in the app — they were at the game. "Off by one or two" was never acceptable.

Screenshots are an API if you're stubborn enough.

The build: Claude Chat as PM, Claude Code as the engineering team

The division of labor across surfaces was one of my favorite parts of this project. Claude Chat was the product and analyst side: it held the league knowledge base, extracted the box scores, wrote the analytics methodology (ERA scaled to six innings, contact-quality definitions, lineup tiers), brainstormed the insight catalog, and finally wrote a complete build brief — design spec, data architecture, API design, roster notes — as a handoff document.

Claude Code took that brief and built the app: Next.js, TypeScript, Tailwind, static JSON processed at build time, no database, Vercel free tier. The first session went from an empty folder to a deployed app with a working stats page in one evening. Later iterations happened from wherever I was — including Claude Code sessions started on my phone that landed as pull requests. About 20 PRs shipped that way during the season: the Lineups tab, mobile layout fixes, playoff data updates.

The timeline still makes me laugh: the scaffold deployed on May 11. Coaches were using it to prep for a real game on May 13.

Design iterations: from wireframe to something you'd show people

The first working version was pure wireframe — black and white, default everything, the stats table cheerfully scrolling underneath the tab bar. One long feedback pass ("this should feel like Airbnb or Apple Health, not a wireframe") brought in the field-green brand, tab icons, merged cards, and the zebra-striped table.

Then came the mobile-web battles nobody warns you about. iOS Safari zoomed the whole page every time you tapped the chat input. The keyboard broke scroll positioning. The modal needed a real slide-up animation. And Scout's carefully formatted analysis arrived as raw asterisks and pipe characters, because markdown rendering wasn't wired up yet:

Details I'm fond of: every stat in an insight carries a league rank ("1st of 10") because a coach can't tell whether 12 extra-base hits is a lot; chat answers got promoted out of bubbles to full-width text because they're analysis, not texting; and the drag-and-drop Lineups tab exists because Scout kept recommending batting orders in prose, and the obvious next step was letting a coach grab a row and move a kid up the order.

The agent: four architectures in ten days

The AI side of Scout went through four distinct versions, each forced by a real failure — I couldn't have designed the final one on a whiteboard, because every architecture was correct until a real coach question made it wrong.

The human layer

My favorite bug report wasn't technical. Scout analyzed one of our pitchers — a kid, and a fellow coach's son — and bluntly advised against pitching him. Statistically defensible; humanly unacceptable. That produced a system-prompt pass on tone: Scout now leads with what a kid is doing well, checks recent form before judging a season line (kids develop fast — the season average is often stale), and frames concerns as things to work on at practice. "Gentle but honest" turned out to be a real product requirement, not a nice-to-have.

Same energy: the insight engine once told our outfielders to "play deeper" against the team with the worst extra-base power in the league. Fellow coaches make excellent QA.

Did it work?

The coaching staff used Scout through the end of the regular season and the playoffs — not in the dugout, but the night before: opponent insights, the lineup builder, and pitching plans. One coach used it to set our batting order and figure out how to align our middle-relief pitching for a Sunday game. The texts started arriving:

The receipts: Scout's agent went live on the evening of May 12, with the Aces sitting at 8–6–2. The first game we prepped with it — May 13, at the Mighty Mussels — we won 22–4. Then came a 9–8 playoff thriller over the Flying Squirrels to reach the semifinal against the top-seeded Rail Riders — and that week Scout got its most serious upgrade: pre-loaded, pitch-level splits on just that one opponent, because that's exactly what a real scouting department does before the biggest game of the year. The run ended there, against the league's best. After Scout shipped, the Aces went 2–1; I won't claim causation, but I'm not not claiming it.

A second team asked to onboard, which is how you know a side project built for four users has legs. Next season I'm tempted to open it to the whole league for league-wide feedback — though youth-baseball coaches are famously secretive about what they're willing to share, so we'll see.

What this project is really about

• AI products are cost-engineering products. The distance between "magical demo" and "thing four people use all season" was mostly context architecture: what lives in the cached prompt, what hides behind a tool, what gets precomputed. Unit economics went from $0.29 to about a nickel per question without losing capability.
• Trust is the product. In a stats app for people who know the ground truth, one wrong number costs you everything. Validation scripts aren't glamorous; they're the product.
• Domain sensitivity is a design surface. Privacy formats for kids' names and a coaching-appropriate tone were as much "the design" as the green accent color.
• The feedback loop is the whole game. Spec in Claude Chat, build in Claude Code, ship to Vercel, get a coach question that breaks it, fix it from a phone before the next game. That loop — not any single feature — is why the thing got good.