RaceEdge: Building a Transparent UK & Ireland Racing Research App

RaceEdge is one of the apps I have been building and testing on this VPS. The idea is simple: take real UK and Ireland racing data, score runners with an explainable model, and show the reasoning clearly instead of pretending a black-box AI can magically pick winners.

It is deliberately a research and decision-support tool. Horse racing involves risk, and RaceEdge is designed to make the assumptions visible: what data was used, why a horse scored well, what the confidence level is, and where the warnings are.

This is not financial advice or a promise of profit. RaceEdge is a software experiment in transparent racing research, paper tracking, bankroll discipline, and evidence-led model building.

What the live app does today

The current live version at raceedge.uk is a Next.js app deployed through Coolify from a private GitHub repository. Coolify reports it as running healthy, exposed on port 3000, and served publicly at the RaceEdge domain.

On the homepage, the app shows a daily dashboard for UK and Ireland racing:

• Today’s date and the active data source.
• A clear “No mock data” badge.
• Counts for meetings, races, and generated tips.
• Top ranked selections with confidence and risk labels.
• Factor-by-factor scoring for each runner.
• Reasoning bullets and uncertainty warnings.
• Today’s meetings with race class, type, distance, runners, and going.

The principle: no fake fallback

One of the most important product decisions is that RaceEdge should not silently swap in fake runners if the real data source fails. If the scraper breaks, an upstream site changes, or a dependency is missing, the app should show an error.

That sounds small, but it matters. A racing app that quietly substitutes mock data can look like it is working while producing meaningless output. RaceEdge is meant to be boringly honest: real data or a visible failure.

Real racecards
  ↓
Transparent runner scoring
  ↓
Ranked tips with reasons
  ↓
Risk warnings and paper tracking
  ↓
Research evidence before any live promotion

The data layer

The MVP has two practical data paths:

• Racing Post public web endpoints via a local low-frequency scraper for free racecard research.
• The Racing API when a configured API key is available.

The current live dashboard is using the Racing Post free scraper route. The scraper is kept behind a data-source interface so the rest of the app can work with the same race and runner objects whether the source is free scraping, a paid API, or a future licensed historical feed.

The scoring model

RaceEdge does not claim to have a trained ML model before the evidence exists. The current model is a transparent weighted scorer that breaks each selection into visible factors.

Examples of the factors shown in the UI include:

• Recent form: how the horse performed in recent starts.
• Class suitability: whether today’s race looks easier or harder than the previous run.
• Race type match: whether the race fits the preferred strategy profile.
• Field size: with a preference for races that match the tested setup.
• Trainer and jockey strike rates: used as supporting signals, not magic answers.
• Going, distance, and course suitability: evidence that today’s conditions fit the runner.
• Value odds and market position: including late market movement when available.

Each tip card then shows a composite score, confidence label, risk label, factor breakdowns, and reasoning. This makes the app feel more like a research dashboard than a “trust me” tipster.

The starting strategy

The preferred starting strategy is intentionally narrow. RaceEdge focuses on UK and Ireland handicaps, with a bias toward class 3–5 races and fields around 8–12 runners.

The first strategy rules look for patterns such as:

• A favourite or near-favourite with recent top-two form.
• Recent activity, usually a run within the last few weeks.
• Strong jockey or trainer signals.
• Distance suitability and, where possible, course evidence.
• Clear warning labels when information is missing or uncertain.

The point is not to make the model complicated. The point is to keep the first version inspectable, testable, and easy to challenge.

Bankroll, paper tracking, and research modes

RaceEdge also has pages beyond the daily tips screen. The navigation includes Dashboard, Races, Tips, Bankroll, Paper, Research, Performance, History, and Strategy.

The bankroll page lets a user enter an available bank and see staking suggestions with guardrails. It supports multiple modes, including backing RaceEdge tips, paper-testing false-favourite lays, and tracking alternative place-style ideas. Overrides above the suggested risk percentage are labelled aggressive with drawdown warnings.

The paper tracking system is a big part of the app. Instead of jumping straight from a backtest to real stakes, RaceEdge can capture daily paper signals, settle them later, and keep separate evidence streams for different hypotheses.

Daily racecards
  ↓
Generate tips
  ↓
Capture paper signals
  ↓
Capture available Exchange prices
  ↓
Settle against results
  ↓
Review evidence before changing the strategy

What I have been testing on the VPS

The VPS has been useful because the app can run like a real product instead of a local demo. The current deployment flow is:

• Code lives in a private GitHub repository.
• Coolify builds the Dockerfile from the main branch.
• The app runs as a Next.js production container.
• Coolify and Traefik route traffic to raceedge.uk.
• The live site can be checked from the same Hermes agent that is editing, deploying, and inspecting it.

That loop is exactly why I like this VPS setup. I can ask an agent from Telegram to inspect the app, read the repository, check the deployment, run tests, and verify the public URL. It turns a rough product idea into something that can actually be exercised in production.

Historical backtests and the reality check

RaceEdge has also been moving toward serious historical validation. The repository includes scripts for importing historical datasets, running baseline strategy reports, testing model grids, and validating false-favourite ideas against Betfair BSP-style data.

The most important lesson so far is that broad racing strategies are easy to make look good in a narrow slice and hard to make robust across years, price sources, and realistic assumptions. RaceEdge therefore keeps research labels explicit:

• Backtested does not mean live-promoted.
• Proxy/SP evidence is not the same as executable Exchange evidence.
• Positive slices need sample size, fold consistency, drawdown control, and price-source validation.
• Weak or contradictory signals should remain paper-only.

The product I want RaceEdge to become

The long-term version of RaceEdge is not just a tip list. It is a transparent racing research workbench: daily cards, scored runners, strategy configuration, bankroll discipline, historical validation, paper tracking, Exchange price evidence, and eventually carefully validated ML models.

The roadmap points toward:

• Deeper historical data pipelines.
• Walk-forward backtesting and strategy optimisation.
• Probability calibration and no-leakage validation.
• Live odds and market movement tracking.
• Better pace, draw, going, course, and trainer-intent features.
• ML only after the transparent baseline and data quality are strong enough.

Why I like this build

RaceEdge is a good example of the kind of app this VPS workflow makes possible. It is not just a landing page or toy demo. It has a real domain, a real deployment, a real data source, a database-backed research layer, and enough moving parts to force honest engineering decisions.

The most useful constraint is transparency. Every time the app makes a claim, I want it to show the ingredients: the score, the factors, the warning signs, and the evidence status. That is the difference between a flashy AI prediction app and a tool I can actually learn from.

You can see the live app here: raceedge.uk.