An AI that manages my fantasy football team.

Before diving into code, I spent time understanding the complexities of football prediction. Player performance isn't just about individual skill - it's influenced by team dynamics, opponent strength, recent form, fixture difficulty, and countless other factors. The challenge wasn't just building a model; it was creating an entire ecosystem that could ingest data from multiple sources, reconcile differences between them, engineer meaningful features, and produce reliable predictions.

The system needed to handle several key requirements:

Rather than building a monolithic application, I designed the system as a collection of specialised components, each responsible for a specific domain. This modular approach meant I could iterate on individual components without affecting the entire system, and it made the codebase much easier to reason about.

The architecture consists of three primary layers. At the foundation, the data collection layer handles the complexity of gathering information from multiple sources. The FPL API provides official game data, whilst Sportmonks offers detailed statistics like expected goals (xG) and pass completion rates. Each collector runs asynchronously, implementing sophisticated rate limiting to respect API limits whilst maximising throughput.

Above this sits the ML pipeline layer, where the real magic happens. This layer transforms raw data into engineered features, handles model training, and manages predictions. I chose Polars over Pandas for data processing - its lazy evaluation and columnar storage format meant operations that took minutes in Pandas completed in seconds.

Finally, the API service layer exposes the system's capabilities through a FastAPI application. This isn't just a simple prediction endpoint; it's a full-featured service with health monitoring, real-time updates, and comprehensive error handling.

One of the most challenging aspects of the project was reconciling data from different sources. The FPL API might refer to a player as "Fernandes B.", whilst Sportmonks calls him "Bruno Fernandes". A naive exact match would fail for most players, so I developed a sophisticated matching system that combines multiple strategies.

The player matcher uses a multi-stage approach. First, it attempts exact matches on known identifiers. When that fails, it falls back to fuzzy string matching using Levenshtein distance, but crucially, it constrains the search space using team information. If a player is listed as playing for Manchester United in FPL, the matcher only considers Manchester United players from Sportmonks.

Raw data alone doesn't make good predictions. The key to the system's performance lies in sophisticated feature engineering that captures the nuances of football performance. This was where I could combine domain knowledge with technical expertise to create features that truly matter.

One of the most critical challenges in time-series prediction is preventing data leakage - accidentally including future information in historical features. Consider calculating a player's average goals over the last five games. If you're not careful, you might include the game you're trying to predict in that average, essentially telling the model the answer.

I solved this through careful use of temporal shifts:

Every feature that uses historical data applies a shift operation, ensuring we only use information that would have been available at prediction time. This might seem like a small detail, but it's the difference between a model that works in backtesting but fails in production, and one that performs consistently in real-world conditions.

Beyond basic rolling averages, the system creates composite features that capture complex relationships. Shot accuracy isn't just about shots on target; it's about the ratio of on-target shots to total attempts. Creative efficiency measures how many big chances a player creates relative to their total key passes. These nuanced metrics often prove more predictive than raw statistics.

Traditional features like "home team" and "away team" treat all teams as categorical variables, missing the dynamic nature of team performance. A team that was strong last season might be struggling this year. To capture this, I implemented a custom Elo rating system that updates after each match based on expected goals (xG) performance.

The Elo system works by maintaining a rating for each team that changes based on match results. When Manchester City (rating: 1850) plays Luton Town (rating: 1250), the system expects City to dominate. If City wins as expected, ratings barely change. But if Luton manages a draw, their rating increases significantly whilst City's decreases.

What makes this implementation special is that it uses expected goals rather than actual results. This means a team that dominates possession and creates chances but loses to a lucky goal still sees their rating improve. Over time, this provides a more accurate measure of team strength than results alone.

The system maintains separate ratings for attack and defence, allowing for teams that might be strong defensively but weak in attack. These granular ratings feed into player predictions, helping the model understand that a striker facing a weak defence is more likely to score, regardless of which specific team they're playing.

With features engineered, the system needed a robust machine learning framework. Rather than implementing models from scratch, I integrated AutoGluon, a state-of-the-art AutoML framework that automatically selects and combines the best models for the task.

The integration wasn't just a simple wrapper. I configured AutoGluon to use its "extreme" preset, which leverages cutting-edge models like TabM (transformer-based), MITRA (foundation model), and TabICL (in-context learning), alongside traditional gradient boosting methods. The framework automatically determines whether each prediction target needs classification or regression, adjusting evaluation metrics accordingly.

GPU acceleration was crucial for training speed. What would take hours on CPU completes in minutes on GPU, allowing for rapid iteration and experimentation. The system automatically detects available GPUs and configures models to use them efficiently.

One subtle but important detail is sample weighting. Recent games are more predictive than older ones, so the system weights training samples based on recency. This isn't just a simple linear decay; it's carefully tuned to balance having enough historical data whilst prioritising recent form.

Building a model is one thing; deploying it to production is another challenge entirely. The system needed to handle real-time updates during live gameweeks, serve predictions with low latency, and recover gracefully from failures.

The FastAPI service implements comprehensive error handling and monitoring. Every endpoint has detailed logging, request validation, and error responses. The health check endpoint doesn't just return "OK" - it verifies database connectivity, checks model availability, and reports system metrics.

Database queries are carefully optimised to minimise latency. Rather than making multiple round trips, complex joins gather all necessary data in single queries:

Throughout development, I obsessed over performance. Every operation was profiled and optimised. Batch operations replace loops wherever possible. Database inserts use `upsert_batch()` to handle thousands of records in single transactions. API calls are made concurrently with careful rate limiting to maximise throughput without overwhelming services.

The choice of Polars over Pandas wasn't arbitrary. For operations on large datasets, Polars' columnar storage and lazy evaluation provide massive speedups. A feature engineering pipeline that took 45 minutes in Pandas completes in under 3 minutes with Polars. When you're iterating on features, this difference is transformative.

Memory management also received careful attention. The system processes data in chunks where possible, avoiding loading entire datasets into memory. Models are loaded on-demand and cached, balancing memory usage with response latency.

These metrics translate into genuine value for FPL managers. During the 2024-25 season, the model consistently identified undervalued players before price rises. For instance, it flagged several budget midfielders who went on to significantly outperform their price point, allowing early adopters to gain team value.

The system's predictions proved particularly valuable during double gameweeks, where the compounding effect of accurate predictions across multiple fixtures provided significant advantages. Users reported average rank improvements of 15-20% when following the model's recommendations compared to their intuition alone.

The modular architecture has proven its worth through easy maintenance and updates. When the FPL API changed their rate limits, updating the rate limiter configuration was a one-line change. When I wanted to experiment with new features, I could add them without touching existing code. The system processes predictions for an entire gameweek in under 30 seconds, fast enough for real-time decision-making during team selection deadlines.

This project pushed me to grow across multiple technical dimensions. I deepened my understanding of time-series prediction, learning the subtle ways data leakage can creep in and how to prevent it. I gained experience with modern ML frameworks, understanding when to use AutoML versus custom implementations.

The importance of good software engineering practices became even clearer. Clean code isn't just about aesthetics - it's about building systems that can evolve. The investment in proper error handling, logging, and monitoring paid dividends when debugging production issues.

Perhaps most importantly, I learned to balance perfectionism with pragmatism. The player matching system doesn't achieve 100% accuracy, but 90% is good enough when combined with proper error handling. The Elo system uses simplifying assumptions, but they're reasonable ones that produce useful results.

The system provides a solid foundation for future enhancements. I'm exploring graph neural networks to model player relationships - perhaps certain players perform better together. Reinforcement learning could optimise team selection over an entire season rather than individual gameweeks.

There's also potential for real-time streaming architecture using Apache Kafka, allowing the system to process events as they happen during matches. In future I would experiment with having individual models for each stat that make up FPL points, however this would require much more powerful hardware as the training times would be phohibitive with my current setup.