Skip to content

Chalk

An intelligence platform for football coaches. Three modules cover film analysis, recruiting evaluation, and game plan recommendations, each powered by a separate reasoning layer built for that specific problem.

Next.js React TypeScript Tailwind CSS shadcn/ui Supabase Groq Llama 3.3 70B Vercel
// the problem

Coaching intelligence is scattered across too many tools

Most football coaches at the high school and smaller college level do their film work in one place, track recruiting in a spreadsheet, and build game plans in their heads or in a whiteboard session. The tools that exist are either designed for major programs with large budgets, or they're general-purpose platforms that weren't built with football-specific context.

The insight behind Chalk was that these three areas, film, recruiting, and game planning, have different analytical needs but they're all part of the same job. A platform that treats them as connected rather than separate could save significant time and surface connections that aren't visible when the data lives in different places.

I'm personally interested in the strategy side of football. The project gave me a chance to apply language model capabilities to a domain where the right framing and football-specific knowledge actually matter, rather than just using generic assistant prompts.


// how it works

Film Room, Board, and Playbook

The Film Room module is where play data goes in. Each play is tagged with down, distance, formation, personnel grouping, concept, and result. When you run the scouting report action, an aggregation layer processes all tagged plays and computes: run/pass split overall and by down, top four formations, top three personnel groupings, top five play concepts, red zone tendencies, third-down splits by distance, and pre-snap motion frequency. That aggregated profile gets passed to Groq's Llama 3.3 70B with a structured prompt template. The model reads the numbers and writes a six-section markdown report: Offensive Identity, Run Game, Pass Game, Third Down, Red Zone, and Key Adjustments.

The Board handles recruiting. You can log prospects with position, measurables, film grades, and contact notes. The evaluation layer scores prospects against configurable position profiles and generates comparison summaries across a recruiting class. It surfaces candidates who match specific scheme fits based on their film data.

The Playbook module is where film analysis feeds into game planning. Once you've built a tendency profile for an opponent in the Film Room, the Playbook can recommend specific play concepts and formation adjustments targeting the tendencies you've identified. The recommendations trace back to the underlying film data so you can follow the reasoning.

The LLM's job is interpretation, not pattern detection. By the time Llama sees the data, the patterns are already identified: run rate on second-and-long is 31%, pre-snap motion appears on 62% of pass plays. The model reads those numbers and writes the analysis. The intelligence is in what gets measured and how it's aggregated, not in the model.

All data is persisted in Supabase. The application is a Next.js frontend deployed on Vercel. The intelligence layer runs on server actions and edge functions, which keeps the client clean and the latency low.


// the technical details

Domain knowledge, module boundaries, and the remote inspection feature

The hardest part of building Chalk was making the intelligence layer actually useful rather than just impressive-looking. Football has a specific vocabulary, and the recommendations need to use that vocabulary correctly to be trusted by someone who thinks in terms of gap schemes, coverage shells, and route concepts. Getting the framing right in the system context took multiple iterations.

The three modules have clean boundaries but shared data. A prospect in the Board can have film notes attached that came from the Film Room. A game plan in the Playbook references specific opponent tendencies logged in the Film Room. The database schema had to support these relationships without creating tight coupling between the modules at the application level.

The aggregation design was where most of the product thinking happened. Deciding what to measure shapes what the report says. Run/pass split overall is obvious; run/pass split by down is where the insight lives. Third-and-short and third-and-long behave differently enough that combining them into a single third-down row loses the information. Pre-snap motion frequency is easy to miss if you're not specifically looking for it. Getting the aggregation right took more iteration than any part of the code.