Scout
Full-stack multi-sport recruiting platform
Stack
- Next.js
- TypeScript
- FastAPI
- PostgreSQL
- Clerk
- Anthropic API
01
The problem
College recruiting runs on access. Athletes with the right club, the right camp, or the right family connections get seen; comparable athletes without those things do not. The filtering happens long before anyone evaluates a highlight reel.
The tooling reinforces it. Recruiting services are priced for families who can absorb the cost, and the free alternative is a spreadsheet of coach emails and a cold outreach campaign that mostly goes unanswered.
Scout started as a soccer-specific answer to that and grew into a multi-sport platform once the same structure turned out to hold across sports.
02
The approach
The core bet is that a structured, comparable athlete profile beats an unstructured highlight reel for discovery. If every athlete's data lives in the same shape, programs can filter, and athletes stop competing on production value.
Expanding from soccer to multi-sport meant separating what is universal — identity, academics, eligibility, contact — from what is sport-specific, so a new sport is a configuration change rather than a fork.
03
Architecture
- Next.js front end, FastAPI service layer
- TypeScript throughout the client with a separate Python API, which keeps the data and model-facing work in the ecosystem that suits it rather than forcing everything into one runtime.
- PostgreSQL as the profile store
- Relational fits the domain: athletes, programs, sports, and the many-to-many interest between them are all joins, and recruiting filters are exactly the queries a relational engine is good at.
- Clerk for identity
- Athletes, coaches, and programs are distinct roles with different permissions. Delegating auth avoids hand-rolling session and role handling on a platform holding minors' data.
- Anthropic API
- Used in the matching and profile layer — turning unstructured athlete and program information into the comparable structure the rest of the platform depends on.