DEV Community: Nilamadhab Senapati

I Resurrected a Dead F1 Project and Accidentally Built a Race Intelligence OS

Nilamadhab Senapati — Sun, 24 May 2026 20:30:28 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

I built F1 Intelligence Studio — a full-stack Formula 1 race intelligence dashboard that turns raw telemetry data into a living, breathing visualization of any race from 2024 to 2026.

Think of it as a race engineer's war room. Twenty animated cars chase each other around circuits drawn from real GPS telemetry. An AI race engineer (Claude) analyzes strategy in real-time. A spring-physics camera zooms into wheel-to-wheel battles like an actual broadcast. ElevenLabs voices the commentary. A strategy simulator answers F1's eternal question: pit or stay out?

You can scrub through any moment of any race with frame-perfect precision. You can compare two drivers' telemetry traces side-by-side, watch tyre stints unfold, monitor team radio, and get AI-powered insights on developing battles.

It started as a single API call dumping data into a table. It ended as a 12-panel drag-and-drop dashboard with twelve interactive components. Somewhere in between, I lost track of where the line was — and that's the whole point of this story.

What this project means to me: It's the first side project I've actually shipped in years. My GitHub is a graveyard of half-built ideas. This one made it out alive.

Demo

🏎️ Live Demo: https://raceosf1.one/
📦 GitHub Repo: https://github.com/nilamadhab47/raceosf1

Quick screenshots:

🟢 The animated track map with 20 cars on a real telemetry-derived circuit

🟢 Telemetry comparison — two drivers, speed/throttle/brake overlaid on the same distance axis

🟢 The AI insights panel — Claude analyzing strategy in real-time and Strategy simulator showing pit vs stay-out delta

The Stack:

Frontend: Next.js 14, TypeScript, Zustand, GSAP, Recharts, react-grid-layout
Backend: FastAPI (Python 3.12), FastF1, WebSocket broadcasting
AI: Anthropic Claude (race insights + chat), ElevenLabs (voice commentary)
Infrastructure: Vercel (free tier) + Railway ($5/month)

Total infrastructure cost: less than my monthly coffee budget. The spring-damper camera system took more math than my engineering degree.

The Comeback Story

Here's the honest version.

My GitHub looks like a graveyard. Landing pages with no backend. ChatGPT chats about apps that never left the chat. Ideas rotting in a documents folder. I'm a full-stack engineer who builds production systems for a living — but my own projects? Couldn't finish a README.

The F1 project was no exception. I started it months ago when Instagram served me a dev reel about FastF1, that incredible Python package for Formula 1 telemetry data. My brain did its usual thing: "Oh that's cool, I should build something." I made a repo. Wrote a few API endpoints. Got driver data into a table.

Then? Procrastination. The classic excuses kicked in:

"Who's going to use this?"
"There's no monetization."
"You're a backend engineer pretending to do frontend."

The repo sat there for weeks. Untouched. Just another tombstone.

What changed:

I made myself one rule. Sit down after work. Fifteen minutes minimum. No "let me plan the architecture first" (the ultimate procrastination disguise). No "I'll start fresh on Monday." Just open the laptop and ship one small thing.

The beginning was ugly. Just ugly. But I kept showing up.

Then the escalation started:

Week 1: Tables turned into graphs. Slightly less boring.
Week 2: Graphs turned into driver comparisons. Wait, this is actually interesting.
Week 3: Comparisons turned into full race simulations. Now I need actual circuit maps?
Week 4: Drawing SVG tracks from raw GPS telemetry. I googled "what is a viewBox" at 11pm. No shame.
Week 5: Twenty animated cars chasing each other at 60fps. Bypassed React's render cycle entirely because setState 60 times a second is a war crime.
Week 6: Added an AI race engineer. Then voice commentary. Then a spring-physics camera that zooms into battles like an actual TV broadcast.

I looked up from my keyboard and realized what started as "let me show F1 data in a table" had turned into a complete Race Intelligence Operating System. My scope creep could lap Verstappen.

The finish-up grind:

When this challenge dropped, the project was mostly working but full of rough edges — the kind of rough edges that keep you from actually showing it to anyone. The "I'll polish it later" backlog. Sound familiar?

Here's what I cleaned up for the final push:

Documentation. The README was a single sentence. Now it's a proper onboarding doc with setup, architecture diagrams, and contribution guidelines.
Error boundaries on every panel. Before, one panel crashing could take down the whole dashboard. Now each panel fails gracefully on its own.
Loading skeletons. Previously the dashboard flashed empty boxes during data fetch. Now everything has proper loading states.
The YouTube content-ID disaster. F1 videos kept showing "Video unavailable" in production because FOM blocks third-party embeds. Built a three-tier fallback: Dailymotion → non-blocked YouTube → thumbnail cards with external links.
Deployment. Three Dockerfile failures on Railway. Path resolution, build context, and the infamous $PORT variable not expanding because Railway's startCommand doesn't run through a shell. Finally got everything green.
Polish pass. Onboarding tour, keyboard shortcuts, mobile-responsive grid presets, dark mode that doesn't look like an afterthought.

The before-and-after gap is the difference between "a thing on my laptop" and "a thing I can show people without apologizing."

The biggest lesson wasn't technical. It's that the beginning lies to you. It whispers "this is pointless" and "you're not good enough" — and if you listen, you add another repo to the graveyard and open Instagram instead.

The only answer is to keep showing up. Fifteen minutes at a time.

My Experience with GitHub Copilot

I used Copilot heavily during the finishing-up phase, and honestly? It's where it shined the most.

The interesting thing about reviving an abandoned project is that the fun parts are already built. What's left is the unsexy stuff — polish, edge cases, drag-and-resize logic, design system consistency. Things I'd normally rage-quit before finishing. This is exactly where Copilot earned its keep.

Where Copilot genuinely helped:

🟢 Drag-and-resize architecture for the dashboard panels. This was the single biggest unlock. I needed every panel to be draggable, resizable, and auto-adjustable based on its container — without breaking the internal components inside each one. Copilot helped me architect the layout system and walked through how to wire react-grid-layout with my existing panel components. The hardest part was making sure that resizing didn't break the SVG track map, the Recharts graphs, or the WebSocket-driven animations inside. Copilot suggested the right patterns — ResizeObserver for container-aware children, debounced resize handlers, key-based remounting for stubborn charts — without me having to re-architect each panel from scratch.

🟢 Type definitions for FastF1 responses. FastF1 returns deeply nested pandas DataFrames that I was serializing into JSON. Writing TypeScript types for these by hand was tedious. Copilot inferred most of them from my Python serializer code and saved me from manually transcribing field names.

🟢 Design system consistency + performance tuning. When I was unifying the visual language across twelve panels (spacing, colors, typography, motion timings), Copilot was great at suggesting consistent token-based patterns and flagging where I'd diverged. It also helped with performance decisions — when to memoize, when to use refs over state, when to virtualize, when not to. Not always right, but a useful second opinion.

🟢 Edge case handling. When I was hardening the API endpoints, Copilot was great at suggesting validation cases I hadn't considered. "What if lap_number is negative?" "What if the session hasn't loaded yet?" The kind of paranoid checks that production code needs but you forget when you're prototyping.

🟢 Test stubs. I wrote one test for the gap-calculation logic. Copilot generated the rest of the test cases by varying the inputs. About 70% were useful, 30% were noise — but the useful ones caught two real bugs.

Where Copilot was less useful:

🔴 The creative architecture decisions. The spring-damper camera, the 1000-point SVG sampling trick, the ref-based animation loop bypassing React — these required actually thinking about the problem. Copilot suggested generic solutions when I needed weird ones. That's fine. It's a tool, not a teammate.

🔴 Anything involving FastF1's quirks. FastF1 has a lot of session-specific behavior (sprint weekends, qualifying formats, telemetry availability) that Copilot's training data didn't cover well. It would suggest plausible-looking code that didn't actually work for the data shape.

🔴 Genuinely novel logic. The first time I wrote the gap-to-track-fraction conversion (offset = gap_seconds / avg_lap_time), Copilot wasn't going to help me derive it. I had to actually understand the math first.

🔴 Hallucinations when my prompt was vague. This is the honest catch. Whenever I got lazy with my prompting — vague intent, no constraints, no examples — Copilot confidently hallucinated APIs that didn't exist, function signatures from imaginary library versions, or completely overengineered a solution I didn't ask for. I'd ask for a small utility and get back a 200-line abstraction with three layers of inheritance. The lesson learned the hard way: the quality of Copilot's output is directly tied to how precisely I describe what I want. Vague in, garbage out. It's not the AI's fault — it's mine for not being specific.

The honest takeaway:

Copilot is at its best when you know what you want and need to type less to get there. It's at its worst when you don't know what you want and hope the autocomplete will figure it out for you. For finishing up an abandoned project — where the hard creative work is already done and what remains is execution polish — it's nearly perfect.

It didn't write my project. But it absolutely helped me finish it.

What's Next

The graveyard still has occupants. This is the first exhumation, not the last. I've got a backlog of half-built ideas and I'm coming for every single one of them.

Because it's not about the money. ~ Brad Pitt, F1

Massive shoutout to theOehrly — the FastF1 maintainer. This entire project exists because you built something incredible and open-sourced it. That's the energy.

If you're sitting on an abandoned project right now, this is your sign. Open the laptop. Fifteen minutes. The beginning is lying to you.

Built with too many late-night qualifying sessions, more cans of energy drink than I'm willing to admit, and a refusal to add one more tombstone to the GitHub graveyard.

I built a tool that shows you exactly what an ATS reads from your resume — here's how it works

Nilamadhab Senapati — Sun, 24 May 2026 18:57:23 +0000

Most resume checkers score your file against keywords. Legible runs the actual parsing pipeline an ATS uses — and shows you the raw output, line by line.

I've spent months helping friends apply to jobs and watching the same thing happen over and over: a great candidate, a beautiful resume, and silence. No response. No rejection email. Just nothing.

Eventually I started asking the question nobody asks: does the company even see this resume?

The answer, increasingly, is no. An Applicant Tracking System (ATS) sees it first. And ATS systems don't see what you see.

What an ATS actually does

When you upload a PDF to Greenhouse, Workday, Lever, Taleo, iCIMS, or any other major ATS, the system runs your file through a five-stage parser:

Text extraction — PDF/DOCX bytes converted to a character stream
Layout analysis — columns, tables, images, header/footer regions detected
Section segmentation — Experience, Education, Skills, etc.
Field extraction — name, email, dates, job titles, companies
Structured storage — fields written to a database the recruiter searches

If any stage fails, your resume becomes invisible. Not rejected. Invisible. Your file is still in the system, but the recruiter searching for "Kubernetes" never finds you because the parser dropped your skills section.

The five most common silent failures

In rough order of how frequently I saw them in testing:

1. Multi-column layouts
Parsers read top-to-bottom, left-to-right across the full page width. Two columns interleave into garbled lines. "Skills Work Experience Python Senior Engineer SQL Acme Corp" — parsed as one job title.

2. Tables for critical content
Most parsers strip table structure entirely. Skills in a table → gone from the recruiter's keyword search.

3. Image-based PDFs
Canva exports, some Adobe Illustrator templates — these flatten text into a picture. The parser sees a blank page. All your content is invisible.

4. Contact info in the PDF header region
The visual top of the page is fine. The actual <header> XML element in the document structure is not — most parsers ignore it entirely. Many popular resume templates use the document header for name and email.

5. Creative section headings
"Where I've Worked" instead of "Experience", "My Toolbox" instead of "Skills" — the parser's section segmenter fails to classify the section correctly.

Every resume coach knows these patterns exist. But nobody could tell you whether your specific resume failed any of them. You'd just keep applying and hoping.

So I built Legible

legible.live — free, no signup, anonymous, ~8 seconds.

Upload a PDF or DOCX. It runs the same five-stage pipeline a real ATS uses, then shows you:

The exact text the parser extracted, line by line, side-by-side with your original
Which sections it detected with what confidence — and which it missed
A strict score and a lenient score (explained below)
The top three concrete fixes, ranked by estimated point gain

No login. No email gate. No "unlock your full report for $29".

Strict vs lenient — and why the gap is the interesting number

Most ATS scanners give you one number. That number is meaningless because the same vendor can be configured very differently across companies. Workday with the modern AI screening layer behaves one way; Workday without it behaves another. Taleo at a Fortune 500 with strict filters is brutal; Taleo at a smaller employer with default settings is forgiving.

So Legible runs two parallel scorers:

Strict mode simulates legacy keyword-matching behaviour: exact string matches, no semantic equivalence, low tolerance for layout deviation. Worst-case enterprise ATS configuration.
Lenient mode simulates modern NLP-based parsing: semantic equivalence (so "Kubernetes" matches "container orchestration"), skills taxonomies, more layout tolerance. Best-case modern configuration.

The gap between the two scores is your parser-dependent risk.

If your strict score is 45 and your lenient score is 88, your resume is a lottery ticket — it'll pass at modern tech companies and fail at legacy enterprises. If both are above 80, you're robust. If both are below 60, the file itself is broken, not the content.

Under the hood

The whole pipeline runs in 3–8 seconds on a 1–2 page PDF.

Text extraction — two engines, cross-checked

I run PyMuPDF and pdfminer.six in parallel and compare outputs. They disagree about 6% of the time, usually on PDFs with embedded fonts or non-standard encodings. When they diverge significantly, I prefer pdfminer's output and surface a warning:

def cross_check_extraction(pdf_bytes: bytes) -> ExtractionResult:
    pymupdf_text = extract_with_pymupdf(pdf_bytes)
    pdfminer_text = extract_with_pdfminer(pdf_bytes)

    larger = max(len(pymupdf_text), len(pdfminer_text))
    if larger == 0:
        return ExtractionResult(text="", warning="no_text_layer")

    divergence = abs(len(pymupdf_text) - len(pdfminer_text)) / larger
    if divergence > 0.15:
        return ExtractionResult(
            text=pdfminer_text,
            warning="encoding_mismatch",
            detail=f"Extractors disagree by {divergence:.0%}"
        )
    return ExtractionResult(text=pymupdf_text)

Column detection

This is the single most important check. I cluster the x-coordinates of every text box on the page and look for a real gap between clusters:

def detect_columns(pages) -> ColumnInfo:
    x_starts = [
        box.x0 for page in pages
        for box in page if isinstance(box, LTTextBox)
    ]
    if not x_starts:
        return ColumnInfo(count=0, confidence=0.0)

    page_width = pages[0].width
    clusters = cluster_by_gap(x_starts, gap=page_width * 0.15)

    # Real two-column resumes have ~30-50% of text boxes in each cluster.
    # Single-column docs with one indented quote don't count.
    if len(clusters) >= 2 and min_cluster_share(clusters) > 0.25:
        return ColumnInfo(count=len(clusters), confidence=0.9)
    return ColumnInfo(count=1, confidence=0.95)

The trick is the min_cluster_share check. A single-column resume with one indented quote will produce two x-position clusters, but one of them contains only 2% of the text. A real two-column resume has roughly balanced clusters. This single check eliminated most of my false positives.

Section segmentation

Uses fuzzy matching against a known-header vocabulary scraped from a few hundred real resumes. I considered training an NER model, but the gain over a well-tuned dictionary lookup didn't justify the complexity at this scale.

The hardest bug to find

PDFs from certain templates put contact info in the actual <header> XML element of the document — not as regular text in the first paragraph, but in the document structure's header region.

PyMuPDF returns this text by default. pdfminer's high-level API doesn't. So on these files, one extractor saw a name and the other didn't, and the cross-check flagged an "encoding mismatch" that wasn't really an encoding issue at all. Fixing this required reading both extractors' layout output and detecting whether contact fields lived in header regions specifically — which turned out to be one of the most useful diagnostics in the tool.

What the corpus showed

I ran the final pipeline on a corpus of 20 anonymised resumes from public sources and personal contributions. 34% had at least one critical parsing issue. The most common: contact info in document headers (silently dropped by most ATS), followed by two-column layouts.

What it doesn't claim

I don't have access to the actual parsers inside Workday, Greenhouse, Taleo, or any other commercial ATS. Nobody outside those companies does.

Legible simulates the documented behaviour of the parsing pipeline these systems share — the failure modes are real, the detection logic is honest, but the scores are not "what Workday literally returned." The methodology page documents every check and every limitation explicitly.

This honesty is the point. Most ATS scanners quote correlations like "99% match with real employer ATS scores." I don't know how they could possibly verify that. Legible tells you what its pipeline found, what that pipeline shares with real ATS behaviour, and what it cannot tell you.

Stack

Frontend: Next.js on Vercel
Backend: FastAPI + async Postgres on Railway
PDF extraction: PyMuPDF + pdfminer.six, cross-checked
Layout analysis: custom heuristics over pdfminer's LT* objects
Scoring: two independent rule-based scorers running in parallel
Recommendations: GPT-4o-mini pass over ranked deductions, with a deterministic fallback if the call fails

One container per service. Nothing fancy.

Try it

legible.live — free, no signup, ~8 seconds.

If you're job hunting, or you know someone who is, send them the link. Thirty seconds and they might find out the resume they've been sending out for three months is being read as a blank page.

I'd love feedback — especially edge cases that break the parser. Reply here, or open an issue on GitHub.

If you found this useful, the methodology page goes deeper on how each check works and where the limits are. And if Legible finds something surprising in your resume, I'd genuinely like to hear about it.