Long-running data platform

F1 API

An F1 data project started in 2018, adapted into an API and a traceable source pipeline for new product ideas.

Problem and user

Make fragmented racing history usable, traceable and reusable across products.

Builders exploring Formula One history and creating data-led fan experiences.

My role

Product builder and engineer

Started in 2018Source archiveCanonical data API

Outcome and status

  • ✓Evolved early race and qualifying parsers into an API and operational tooling.
  • ✓Established source archives, coverage checks and unresolved-record visibility.

Key product and technical decisions

  • Preserve original source material alongside normalised data.
  • Resolve imported records to canonical IDs.
  • Keep legacy archives separate from the application source of truth.

Learning

Years of accumulated data only become a dependable asset when provenance and identity are explicit.

Next step

Improve historical coverage and validation while testing new fan-product uses.

Build notes and lessons

TL;DR

An F1 data project started in 2018, adapted into an API and a traceable source pipeline for new product ideas.

A project that has grown with the builder

The F1 API did not begin as a newly packaged platform idea. Its repository history reaches back to August 2018, when the work began as a Formula One data project. Early commits record offline source collection, parsing qualifying and race results, and adding SQL persistence. By September 2018, the project was working through the details of qualifying columns and race-result normalisation.

It started with a fan’s curiosity and an engineer’s instinct to make the information usable. Racing history is rich, but it is distributed across pages, tables, changing formats and different identifiers. Turning that material into a consistent dataset became a long-running exercise in acquisition, interpretation and modelling.

From scraping pages to preserving evidence

The early source material has remained useful. The current workspace retains archived HTML from the original project and provides an importer that records source content, paths, hashes, inferred seasons and URLs. This gives the newer system a way to inspect where a record came from rather than simply trusting a transformed row.

That continuity is the important back story: the project has been adapted over years rather than discarded each time the technology or product idea changed. Old work now serves as import material and historical context for a more explicit data pipeline.

A clearer source of truth

The current API uses a canonical application schema. Legacy and archive schemas remain import material rather than competing application sources. Catch-up tooling resolves available sources to canonical IDs, while status and unresolved-record views make gaps visible.

This moves the engineering problem beyond scraping. Identity, coverage and provenance determine whether the data can support a dependable product. Separate API and admin tooling provide a place to inspect those questions, and a showcase explores how the underlying data might contribute to richer fan experiences.

Adaptation without rewriting the history

The broader workspace includes experiments around fan intelligence and personalisation. Those are directions and product explorations, not evidence that a fully scaled personalised platform has already launched. The established asset is the accumulated data work and the system being built to make it traceable and reusable.

What this work demonstrates

The F1 API is a story of sustained technical curiosity becoming infrastructure. It shows early hands-on parsing evolving into clearer operational boundaries, explicit source handling and new product possibilities. The next phase is to improve historical coverage and validation, then test the fan experiences that genuinely benefit from that foundation.

Other product work

View all work →