Full-stack sports platform · League analytics · Operations
I built the league's public data product and much of the operational infrastructure behind it: a multi-season statistics database, public analytics pages, commissioner tools, captain scheduling, data-ingestion workflows, and interactive league features.
The project grew from a statistics site into a full league-management platform. The frontend is designed for players and fans; the backend handles the repetitive operational work that would otherwise live in spreadsheets, text threads, and manual edits.
Sortable standings and statistics, schedules and series results, team and player pages, awards tracking, power rankings, playoff probabilities, historical records, and the ND Wiffle Grid turn league data into a browsable public product.
A Cloudflare-hosted application backed by structured SQL data, API endpoints, validation logic, and authenticated operational tools. Commissioner and captain workflows sit on the same data model as the public site rather than relying on a parallel spreadsheet.
These compact interface views show the kinds of interactions supported by the live site without reproducing every page of the application here.
The frontend is intentionally broader than a leaderboard. It treats the league as a persistent sports data product with navigation, history, context, and interactive tools.
Current standings, full-standing splits, games-back logic, close-game records, strength-of-opponent context, playoff probabilities, and power rankings.
Sortable batting and pitching leaderboards, team filters, player-to-team mapping, player pages, and multi-season historical records.
Calendar and series-centered views, home/away designation, completed game scores, pitcher records, recent-series presentation, and season-progress tracking.
Awards tracking, roster-aware eligibility rules, the historical ND Wiffle Grid, visual result components, and commissioner-facing graphics workflows.
The backend is where the project became substantially more than a static portfolio exercise. The same database supports public analytics and internal league operations.
Public pages and server-side functions are deployed on Cloudflare, keeping the application close to its data and operational APIs.
League records are stored as relational data rather than hard-coded page content, allowing current-season views and historical features to share the same source of truth.
The captain portal uses identity-aware access and team assignments so captains can manage only the availability associated with their team.
Availability and scheduled-series records are checked against one another before writes are accepted, reducing the manual scheduling errors common in spreadsheet workflows.
The result is a project that combines product design, database work, sports analytics, frontend development, access control, and day-to-day operational problem solving.