Predicting football matches with a local AI: a weekend project that keeps score

Here is a project that teaches more about working with AI than any tutorial about summarising documents: predict this weekend’s football results, then keep score of how wrong you were.

It is fun, it takes an afternoon, and it has a property most AI demos lack. There is a right answer, and it arrives on Saturday. You cannot fool yourself about whether it worked.

Let me be clear at the top about where this goes, because the honest version is more interesting than the pitch. You are not going to beat the bookmakers. The value here is learning to build something whose output can be checked, and then checking it.

Why this is a good learning project

Most AI projects have no scoreboard. You ask for a summary, you read it, it seems fine, you move on. There is no way to know if a different prompt would have been better, so you never learn anything.

Football has scores. Every prediction you make gets graded within a week, by reality, for free. That turns a vibes-based exercise into an actual feedback loop, and the feedback loop is the thing worth building.

The shape of it

Trigger: a schedule, Friday evening.

Steps:

1. Fetch this weekend’s fixtures for one league.
2. For each fixture, fetch recent form for both teams.
3. Ask the local model for a prediction, in a fixed format.
4. Write every prediction to a running list.
5. On Monday, fetch the results and score last week’s predictions.

Step five is the one people skip, and it is the entire point.

The odds step is there to score the predictions against the market, which is the part that tells you whether any of this is adding information. It is the evaluation, not a tip sheet.

Getting the data

Use one league. The Premier League, or whatever you actually watch. Ten fixtures a week is plenty and keeps you inside every free tier.

Free football data APIs give you what you need: upcoming fixtures, recent results, and the table. You will want, per team, something like the last six results, goals scored and conceded, home or away, and current league position.

Two things worth doing here that are not obvious:

Fetch form separately for home and away. Home advantage in football is real and substantial, and a team’s away form is often a different team entirely. Collapsing them loses your single most predictive feature.

Include the date of each result. A 4-0 win last week and a 4-0 win in August are not the same evidence, and the model will treat them identically unless you tell it otherwise.

The HTTP node handles the fetching. The transform step is where you shape the response into something compact, because dumping raw API JSON into a prompt wastes most of your context on field names.

The prompt, and the mistake everyone makes

First instinct:

Who will win, Arsenal or Chelsea?

You will get a confident paragraph about Arsenal’s attacking depth and a prediction. It will feel insightful. It is worthless, because it is not grounded in anything you gave it and you cannot compare it to anything.

What you want instead:

Here is the recent form for both teams. Home team: {home_form}. Away team: {away_form}. Home team league position: {home_pos}. Away: {away_pos}.

Give me exactly this, and nothing else:

• Probability of home win, draw, away win. Three numbers, summing to 100.
• Most likely scoreline.
• The single strongest signal in the data above, in one sentence.
• Confidence: high, medium, or low.

Base this only on the data provided. Do not use anything you remember about these clubs.

Three things this does.

It asks for probabilities, not a winner. “Arsenal win” cannot be scored properly. “Arsenal 55%, draw 25%, Chelsea 20%” can, and it forces the model to express uncertainty rather than hiding it behind confident prose.

It fixes the output shape, so you can parse it into a list and score it later without writing a parser for freeform text.

It tells the model to ignore what it remembers. This one matters more than you would think. A model’s training data has opinions about football clubs that are years stale and reputation-weighted. You want a prediction from this season’s form, not from a general sense that Manchester United are good.

Keeping score, which is the actual project

Write every prediction to a running list before the matches happen. Fixture, date, your three probabilities, the predicted scoreline. Then on Monday, add the real result.

After six weeks you will have around sixty predictions and can ask the honest questions.

How often was the highest-probability outcome correct? Baseline to beat: always predicting a home win gets you roughly 45% in most leagues. If you are below that, the model is actively hurting.

Are the probabilities calibrated? Take every match where it said 60%. Did about 60% of them happen? A model that says 80% and is right half the time is not a bit wrong, it is badly broken, and calibration is the measure that catches it when accuracy does not.

Does confidence mean anything? Split by the model’s own high/medium/low. If the “high confidence” predictions are no better than the low ones, that field is decoration and you should drop it.

And the real test: compare to the bookmaker’s implied probabilities. Convert the odds into percentages, and check whether your model is right more often than the market. This is where the project delivers its actual lesson.

What you will find

You will land somewhere around 50 to 55% on outcomes. That beats random and it beats always-predict-home by a little.

It will not beat the odds. The market has already priced in the form you fed the model, plus injuries, plus lineups, plus money from people who know more than both of you. You are competing against an aggregation of everyone’s information with a model reading six recent results.

This is the good news, seriously. You have just learned, cheaply and concretely, what “the model sounds confident and is not adding information” looks like from the inside. That intuition transfers to every AI project you will ever build, most of which have no scoreboard to teach it to you.

There is one honest way to improve it: give the model something the market prices slowly. Team news, a manager’s press conference, a late injury. That is a real edge and it is also real work, and at that point you are not doing a weekend project any more.

A note on betting

Do not bet on this.

The section above is not modesty. A model that is right 53% of the time, against odds that already contain that information and carry a margin, loses money steadily. The maths is not close.

If gambling has stopped being a bit of fun, GamCare and BeGambleAware are there in the UK, and most countries have an equivalent.

Why local matters here

Running a prediction on every fixture in a league every week, plus the scoring pass, plus the six versions of the prompt you will try before settling, is a lot of calls. Through a metered API you would feel it, and more importantly you would start economising, which means you would run fewer experiments and learn less.

On your own machine it is free. That is what makes the iteration loop possible, and the iteration loop is where the learning is. It is a small example of the general point about local models: when calls cost nothing, you try things you would otherwise talk yourself out of.

Build it

If automations are new to you, start with the basic shape, then come back. The nodes you need here are HTTP request, transform, ask AI, and keep track.

The scoring pass is the part to build first, oddly. Build the thing that grades you before you build the thing that predicts, and you will be honest with yourself from run one.

See how automations work or download Halo.