Building F1 Dashboard: From Netflix Fan to Full-Stack Developer

How It Started: From Drive to Survive to Code

So a few years ago, I was just your typical Netflix F1 convert. Drive to Survive had me hooked. But somewhere between season 2 and season 3, I started noticing something. It’s not just about fast cars going vroom. Behind every overtake, every pit stop, every corner is absurd levels of engineering. Teams spend millions just to shave off a tenth of a second.

Being a CS guy, I got obsessed with the numbers. The raw data. Brake patterns, throttle inputs, speed traces, tyre degradation. The drama isn’t just drivers yelling on the radio. It’s in the telemetry. An undercut that gains 1.2 seconds. A pit stop 0.3 seconds slower than your rival. Hitting that delta lap time by 0.001 seconds. This is F1 distilled down to pure problem-solving.

But here’s the annoying part: there aren’t many good tools to dig into this data yourself. You can watch the race. You see the gap charts on broadcast. But actually diving into 60fps car positioning, telemetry comparisons, strategy analysis? Yeah, not so much. That frustrated me enough to build something.

Introducing F1 Dashboard

I’m excited to announce F1 Dashboard, now live at f1dashboard.geraldng.com.

It’s a clean, minimal race analysis tool built to scratch that curiosity itch. Pick any recent F1 race and explore:

• Live track visualization (60fps animated car positions on an SVG circuit map)
• Telemetry comparison (overlay two drivers’ speed, throttle, and brake traces)
• Leaderboard with context (standings, position gaps, tyre compounds, pit stop history)
• Tyre strategy view (stint bars showing when drivers pit and what compounds they’re on)
• Gap evolution (how the gap-to-leader changed throughout the race)
• Race control (flags, safety cars, and official FIA messages)
• Weather data (track temperature, air temp, wind, humidity)

It’s designed to be intuitive for casual fans but deep enough for data nerds.

The Technical Journey

The Challenge: Handling Real-Time Data at Scale

So the core technical challenge was data volume. The FastF1 Python library gives you tons of F1 data, but we’re talking hundreds of data points per lap per driver, across 20 drivers, over 50+ laps. Transforming all that into something smooth and interactive on the frontend? That’s where things got tricky.

Two specific problems gave me grief:

1. Coordinate Transformation F1 telemetry comes as raw GPS coordinates. I needed to convert those into SVG screen coordinates so the cars appear in the right spots on the track visualization. Doing this accurately for 20 different track layouts while keeping animations smooth at 60fps was no joke.

2. Data Pipeline Efficiency The backend has to fetch race data from FIA archives, cache it, and serve it up without bottlenecks. Keeping response times under 100ms meant careful thinking about caching strategies and query optimization.

The Stack: Full-Stack with Purpose

Backend:

• FastAPI for a lightweight, async-first Python server
• FastF1 library for F1 data extraction from official FIA sources
• pandas & numpy for efficient data manipulation and calculations
• Deployed on Railway (with a PostgreSQL cache layer for session data)

Frontend:

• Next.js 15 with React 19 for a modern, fast app shell
• TypeScript for type safety across components
• Zustand for predictable, minimal state management
• Recharts for interactive charts (gap evolution, lap time distribution)
• Tailwind CSS for consistent, responsive design
• SVG-based animations for the 60fps track map with GSAP tweens for smooth car movement

Key Technical Decisions

1. Async data loading — Backend fetches and processes race data on-demand, caching results to avoid re-fetching. First load takes 10–30s (Downloading the telemetry from FastF1), subsequent loads are instant.

2. Coordinate-based positioning — Rather than trying to render complex DOM elements for every car, we use an SVG-based coordinate mapper that transforms GPS lat/lon to screen space. This keeps animation performant even with 20 cars moving.

3. State persistence — Zustand store syncs selected race, selected drivers, and UI preferences to localStorage, so users can pick up where they left off.

4. WebSocket-ready architecture — While the current version serves static sessions, the architecture is designed for real-time race updates via WebSocket (coming soon).

What Makes This Project Special

At its core, F1 Dashboard is a love letter to data. It’s proof that the intersection of curiosity, craft, and technology can produce something both beautiful and useful.

For F1 fans, it’s a tool to understand the sport deeper.
For developers, it’s a case study in real-time data visualization, full-stack architecture, and handling complex state.

What’s Next

This is just the first version launched with the core experience, but there’s so much more on the way:

• Strategy simulator — “What if?” pit stop scenarios with position predictions
• Enhanced replay engine — frame-by-frame playback with interpolation at any speed
• Race predictions — data-driven forecasts for championship outcomes
• Mobile support — responsive layouts for tablet and phone viewing

Try It Out

Head over to f1dashboard.geraldng.com to explore recent races. Pick your favorite driver, zoom into their telemetry, and see what I see in the data.

And if you have feedback—features you want, edge cases you found, or just want to chat about F1 and tech—reach out. I’m building this in the open, and I’d love to hear from you.

---

The Takeaway: Sometimes the best projects start with a question: “Why doesn’t this exist?” F1 Dashboard is my answer to that question. It’s full-stack development, data visualization, and F1 fandom combined into one live product.

Now, go watch some races. 🏁