Back to the work
The F1 Network · 03 of 21

The F1 Network

One backend. Five front-ends. Formula 1 data, unbundled.

What it is

A network of five Formula 1 information sites, each targeting a different reader and a different corner of search. Results is for casual fans who want the weekend's outcome. Data is for stat obsessives who want to compare any two drivers across any era. Info is for insiders who read FIA documents and team radio transcripts. Insights is for strategy nerds who want AI-generated race analysis. Expo is for the events side of the sport.

All five are the same Postgres database underneath.

Why I built it

Formula 1 data on the open web is fragmented across the official F1 site, Wikipedia, a handful of stat blogs, and a couple of dataset repos on GitHub. The underlying data (F1DB) is open and CC-licensed. Every site that fronts this data has its own brand, its own angle, its own reader.

The question I kept asking was: if you've already paid the cost of ingesting the data once, why would you only build one site on top of it?

So I didn't.

How it works

The backbone is a Turborepo monorepo managed with pnpm workspaces. One Hono API service on port 3000. One cron worker that pulls from F1DB on a schedule and writes to Postgres. No ORM — just raw pg. The decision to skip an ORM was deliberate: the schema is stable, the queries are few, and raw SQL is faster to write and faster to read than most ORMs for this scope.

Five independent Next.js apps consume the API, one per domain. Each app has its own branding, its own components, its own SEO surface, its own editorial angle. They share nothing at the UI layer. They share everything at the data layer.

Railway hosts the backend. Each front-end deploys independently.

The marginal cost of the next front-end, after you've built the first one, is about two days. That's the whole thesis.

What I learned

One pipeline and many front-ends is a shape that compounds. Each front-end can be targeted at a different keyword cluster without cannibalising the others, because the content angles are genuinely different. Results ranks for "F1 standings." Data ranks for "Lewis Hamilton vs Michael Schumacher career stats." Insights ranks for long-tail strategy analysis queries. Same database, different surfaces, non-overlapping traffic.

I also learned that refusing to use an ORM makes the whole codebase smaller and easier to reason about, for this shape of project. Not a universal principle. A specific one.

Where it's at now

All five sites live. The data pipeline runs automatically. New content angles can be added without touching the ingestion layer. DiecastF1 (the Shopify storefront) and CDC-Management (the ops system behind it) round out the F1 cluster as affiliate and inventory monetisation.

Coming soon
A build walkthrough

A longer write-up on the F1 Network architecture — the Turborepo setup, the cron ingest, the decision to skip an ORM, and the playbook for spinning up a sixth domain on the same backbone. Drop your email on the main page if you'd like to know when it's up.