← Back

How It Works

SmartPlay does two things: it predicts how many FPL points each player will score (xPts), then it optimises your squad — finding the best transfers, captain, and lineup given your budget and the rules. Here's how both pieces work, how we know they're accurate, and where they fit in the broader FPL prediction landscape.

Backed by published research

SmartPlay's feature engineering is built on OpenFPL, an open-source FPL prediction framework created by Daniel Groos at Groos Analytics. His published research is one of the most rigorous open evaluations of FPL prediction models to date.

OpenFPL computes 251 features from publicly available FPL and Understat data — rolling averages, team and opponent strength, fixture difficulty, availability signals, and more. SmartPlay uses this same data pipeline, then runs its own prediction engine on top: a position-specific multibucket base plus the v12 direct-points blend for defenders, midfielders, and forwards. Goalkeepers remain on the base model because the direct blend did not improve their validation results.

The pipeline

01
Step 1
Data

Collects 251 stats per player per gameweek from the FPL and Understat APIs

02
Step 2
Minutes

Estimates how likely each player is to start and play significant minutes

03
Step 3
Base model

Runs position-specific models for appearance and points outcomes

04
Step 4
v12 blend

Blends the base with a direct points model for outfield players

05
Step 5
Solver

Finds the best transfers, captain, and lineup for your squad and budget

Steps 1–4 produce xPts — a predicted score for every player every gameweek. Step 5, the solver, takes those predictions and works out what you should actually do with your squad.

From predictions to decisions

xPts tell you how many points each player is likely to score, but they don't tell you what to do. That's the solver's job. It takes your current squad, your budget, your free transfers, and xPts for every player across multiple upcoming gameweeks, then finds the mathematically optimal plan.

Under the hood, it's a mathematical optimiser powered by HiGHS, a high-performance open-source solver. It respects every FPL rule — max 3 per team, valid formations, budget constraints, transfer costs — and looks ahead several gameweeks to avoid short-sighted moves.

Captain selection is baked into the optimisation itself, not bolted on as an afterthought. The solver uses conditional xPts — expected points given the player starts and plays significant minutes — so it naturally favours nailed-on starters for the armband. Bench order is also adaptive: when your starters are rotation risks, the solver values a strong bench more highly.

Inputs
  • Your squad, bank & free transfers
  • xPts for all players (multi-GW)
  • All FPL rules & constraints
Outputs
  • Best transfers to make
  • Captain & vice-captain pick
  • Starting lineup & bench order

The solver looks several gameweeks ahead, weighting this week more heavily so it doesn't sacrifice short-term points for a speculative payoff in GW35. It handles all four chips (Wildcard, Free Hit, Bench Boost, Triple Captain), and automatically compares scenarios — rolling a transfer vs. taking a hit, playing a chip now vs. saving it — so you can see the trade-offs before committing. Results come back in seconds.

How we test

v12 was tested in four non-overlapping walk-forward windows covering 32 gameweeks of 2025-26. For each window, the model trains only on data available before that window, then predicts the later matches. The early-season fold trains through 2024-25; the other folds advance the training cutoff through 2025-26. No test-window result is allowed into its own features or training labels.

Earlier data only
8-GW unseen window × 4

Data quality

Predictions are only as useful as the data behind them. Every pipeline run passes through four validation layers and 50+ automated checks before anything reaches you. If something goes wrong, the system rolls back to the last known good state automatically — you never see broken data.

QA
Validate

Every incoming API response and every computed prediction is checked for completeness, valid ranges, and internal consistency before it can be published.

OK
Guard

Hard constraints block bad data at publish time — missing values, out-of-range numbers, and duplicate records are caught and rejected automatically.

RB
Rollback

After publishing, the system re-checks the live data. If anything looks wrong, it automatically restores the previous good version and alerts the team.

Every check is logged, every result is traceable, and the team is alerted within seconds of any anomaly. We track performance at every step so we can spot issues before they become a problem.

Per-Gameweek Accuracy

The production v12 blend against its v11 base on identical 2025-26 walk-forward rows. The charts show every published evaluation gameweek, including players who did not reach 60 minutes.

Ranking accuracy (Spearman)

Did the model correctly predict who would outscore whom? 1.0 means perfect ranking, 0.0 is random. It doesn't care about exact scores — just the order. Higher is better.

Prediction error (MAE)

How far off were the predictions, on average? Measured in FPL points. v12 averages about 0.98 across the published walk-forward windows. Lower is better.

Top-pick ranking (NDCG@10)

Did the players with the strongest actual returns appear near the top of the model's list? Higher is better.

What changed in v12

v12 keeps the calibrated v11 multibucket prediction as its foundation. For defenders, midfielders, and forwards, it blends that output 75/25 with a direct XGBoost points regressor. Goalkeepers stay entirely on v11. This is a measured model upgrade with no new production data dependency, not a wholesale architecture change.

Across the 32 walk-forward gameweeks, mean MAE moved from 0.994 to 0.979, with v12 lower in every gameweek. NDCG@10 moved from 0.352 to 0.380, improving how the model orders the highest-value picks.

Full-pool Spearman was effectively flat: 0.728 to 0.729, and the confidence interval on that change includes zero. We therefore describe v12 as a consistent error and top-pick ranking improvement, not as a dramatic jump in every metric.

What the model can't do

Football is inherently unpredictable. No model can foresee red cards, injuries during a match, penalty decisions, or a 30-yard screamer. In the published v12 walk-forward suite, average absolute error is 0.979 points per player-gameweek. The early-season window is harder at 1.078, and football outcomes remain noisy. These numbers support comparisons across the player pool, not exact-score promises.

The model is strongest at ranking — identifying which players are likely to outscore others — rather than predicting exact point totals. That's why ranking accuracy is the metric we care about most. The v12 research score balances full-pool Spearman with NDCG@10 so improvements at the top of the ranking are not hidden by a season-wide average.

The evaluation comes from one scoring-era season and covers 32 of 38 gameweeks; GW9-14 was not in the published selection suite. Newly promoted clubs, transfers without Premier League history, and early-season minutes uncertainty remain the main live risks.

We update this page as the model evolves. The full codebase is on GitHub. If you have questions, reach out at [email protected].