College football, beyond the scoreboard

I've followed college football since I was a kid. When the BCS came along, I became interested in how the rankings worked. I wanted to understand the calculations behind the decisions, and that curiosity stayed with me.

I was especially interested in the Mid-American Conference, where teams receive less attention. I wanted to look beyond the record and understand how those teams actually played. Learning statistics such as expected points added, or EPA, gave me another way to look at a game.

That interest eventually led me to building models and comparing their predictions with the betting lines. I wanted to get better at handicapping games. When my numbers disagreed with the market, I wanted to understand why. CFB Model Lab became the place where I could work through those questions.

I started with the CollegeFootballData Starter Pack and Model Training Pack because the Python and modeling work were unfamiliar to me. The examples gave me somewhere to begin. I used AI coding tools to help turn them into an application while I learned how the pieces worked.

Over roughly a year and a half, I kept trying things, getting stuck, and starting again. The first attempt went wrong in all kinds of ways. More capable coding tools helped with the second attempt, but so did having a better understanding of what I was asking them to build.

The interface was the part I knew how to think through. I could use my day-to-day UX skills to decide what belonged together, what needed an explanation, and how to make the research useful when I came back to it the next week.

The landing page brings the week's games, my model's projections, and the market lines together. I can look through the slate, find a disagreement, and choose a game to investigate. That became the starting point for my weekly research.

I kept the selected matchup beside its supporting evidence so I could examine the prediction without losing the comparison. A large gap between the model and the market gives me a reason to look closer. The results still have to show whether there was an advantage.

I also keep the model's performance and my own betting record in separate views. The model still needs tuning, and the results haven't been great. I wanted a place to keep track of those results and go back over the calls that didn't work out.

I added the full 2026 schedule and individual team profiles so I could move from a game into the teams behind it. As I learned more, I added different rating systems to compare how they assessed the same programs.

Buffalo gives this flow a concrete starting point. From the schedule, I can open the Penn State game, then follow Buffalo into its profile. The game asks how the teams compare this week. The profile helps me step back and look at how Buffalo has played over time.

Putting those views together helped me work through an important distinction: a team's history and this week's forecast answer different questions. I kept the raw curve separate from the ratings that account for opponent strength, with the partial-season label beside the chart. Otherwise, similar-looking numbers could invite a comparison they cannot support.

The season explorer gave me a way to see teams together on a chart. It puts offense and defense on separate axes, with filters for season and conference. I can look for a pattern across the field, then narrow the comparison to one conference.

I connected the filters, chart, and sortable table so I could move from a visual impression to the actual values. Working on that connection was a chance to practice data visualization with a subject I already wanted to spend time exploring.

I also wanted to compare teams that weren't scheduled to play each other. That became the hypothetical matchup tool. I can choose two teams, compare their strengths, and change the venue to see how the projection responds.

I brought the team comparison and prediction into the same view. Changing the venue makes the home-field assumption visible, and the team statistics give me something to examine alongside the result. These hypothetical games stay separate from the schedule and its market lines.

The Lab grew as I tried different ways of researching the game. Backtests, rating comparisons, and detailed statistical views each gave me another way to examine what I was seeing. The collection reflects the questions I kept coming back to.

The fourth-down explorer is one example. It lets me look at how often teams go for it in different score situations and how that behavior has changed over time. Historical play data becomes something I can explore through charts and a searchable team table.

The heatmap asks how the situation changes a decision. The team chart asks who tends to go for it. Keeping counts beside the rates makes the thin samples visible. I carry that same concern into the application, where a percentage needs enough context to be useful.

Season previews gave me a different challenge. I wanted to take a season's worth of information and turn it into detailed research reports I could return to. That meant deciding what mattered and organizing it into something readable.

I wanted all of this in one place I could keep developing, without paying for another research service. The schedule, team research, experiments, and results became parts of the same personal workspace.

Picking the winner and estimating a win probability are different tasks. If a model repeatedly says 75 percent, I want to know whether those teams win about three games in four. That question became the calibration view.

The chart is paired with a table of probability ranges, game counts, predicted rates, actual rates, and the gap between them. Expand a week to inspect its contribution. Keeping the sample size beside the percentage matters: a bucket with six games should not look as settled as one with more than a hundred.

Brier score and log loss add another way to question the model. Both evaluate the probabilities; log loss penalizes confident mistakes more strongly. The interface explains those measures alongside winner accuracy, without treating any of them as profit.

I learned to separate a description of what a team has done from a prediction of what it might do next. The opponent-adjusted efficiency board describes completed play. A separate local SRS workflow estimates team strength from scoring margins and opponent strength, with prior-season carryover, venue adjustments, a cap on large margins, and separate overtime treatment.

The probability model combines several statistical approaches to estimate how likely a team is to win. Twelve statistical families each contribute offense and defense values for both teams. That makes 48 adjusted inputs; talent and Elo for each team bring the total to 52 continuous inputs. Week and conference are additional categorical fields.

Following the supplied Model Training Pack's recipe, logistic regression, XGBoost, and random forest feed a logistic combining model. A separate margin workflow predicts a point difference. The hypothetical matchup screen converts its margin to a win estimate, so I keep that conversion distinct from the trained probability model.

External ratings need the same care. The research importer keeps provider variants and capture times, matches team identities, and preserves each source's venue convention. Adding home advantage twice, or treating a season-end rating as a pregame observation, would produce a plausible-looking comparison with the wrong meaning.

In September 2026, I investigated whether CollegeFootballData's opponent-adjusted season metrics could replace inputs in my pregame model. All 134 teams in the captured season matched. Ten of the twelve statistical families had candidate fields. That looked promising, until I checked when those numbers were known.

The source supplied season-level metrics without a verified pregame cutoff. A full season's numbers cannot stand in for what was known before a particular game. The compatibility report therefore kept zero valid comparison pairs and left the existing model unchanged.

I directed the product and developed it with coding agents. My work includes the interface, public API integrations, Python rating and modeling workflows, and implementation review. Building the application gave me a reason to learn what happens to the data before it reaches the screen.

Python prepares the data, and SQLite and static JSON carry it into the Next.js and React application. Behind the charts are opponent-adjusted statistics, SRS and Elo ratings, and separate models for margins and probabilities. Learning those distinctions helped me decide how to describe the numbers in the interface.

The CollegeFootballData packs remain the foundation, and the opponent-adjustment work uses Bud Davis's published ridge-regression method. I extended those starting points into the research workflows and application shown here.

A missing statistic could change whether I could make a comparison. A model's limitations could change the words I used around a result. Working through those details brought the data work and my design practice together.

The model still needs work. I now have a place to investigate football questions, keep track of the answers, and try something else when an approach doesn't hold up. Building it has let me follow my design decisions further into the software that makes them work.