FuelGuard

Inspiration

Fuel theft isn't a hypothetical problem—it's a business-killer we've watched firsthand. We (Hussam, Aneeqa, Ahmed and Sumit) come from families running small transport businesses in Hyderabad, and we've seen how fuel just disappears: siphoned overnight, slow leaks, or drivers idling for hours behind warehouses. Fleet managers usually catch it at month-end when the accounting doesn't add up. By then, the driver is three routes away, the CCTV footage is overwritten, and you're just writing off the loss.

One statistic we couldn't shake: 75% of small businesses in developing countries lose over $1,000 monthly to fuel theft. We wanted to build something that lets a dispatcher pick up the phone while the truck is still parked at the site, not three weeks later when the spreadsheet is bleeding red.

What it does

FuelGuard is a real-time fleet dashboard focused entirely on fuel economy and tank levels. Instead of generic GPS tracking, it is designed to catch theft as it happens.

The core of the platform is a dual-path theft detection algorithm. It cross-validates gauge readings against mileage patterns to filter out standard sensor noise. Mathematically, we calculate the expected fuel consumption based on distance and historical efficiency ($E_{historical}$ in L/100km):

$$ \Delta F_{expected} = \left( \frac{\Delta \text{Odometer}}{100} \right) \times E_{historical} $$

If the actual fuel drop ($\Delta F_{actual}$) exceeds this expected drop by a noise threshold ($\epsilon$) while the engine RPM is low:

$$ \Delta F_{actual} > \Delta F_{expected} + \epsilon $$

...the system fires an alert in under a second.

The dashboard tracks up to 10 vehicles simultaneously, calculates per-driver eco-scores, and shows mileage efficiency trends. Because fleet managers often work in areas with dead cellular zones, FuelGuard is built as an offline-first PWA. Entries queue locally and silently sync the moment a connection returns.

How we built it

Frontend: We built the UI with React 19, Vite (fast HMR was non-negotiable since we were tweaking the alert UI every 20 minutes), and Tailwind CSS 4 for rapid grid prototyping.
Data Visualization: We used Recharts because it natively respects the React state lifecycle, which was crucial for live data syncing.
Offline-First Storage: We implemented an IndexedDB queue with strict transaction management to handle background sync without data drops, bundled as a PWA via Workbox.
Mapping: We used the Google Maps API with a seamless fallback to Leaflet/OpenStreetMap for instances where API keys aren't configured (like in our local demo mode).
Backend & Auth: An Express.js server handles rate-limiting and VAPID push notifications, while Firebase (Auth + Firestore) manages data persistence.

Challenges we ran into

Visualization Bottlenecks: Recharts was choking under multiple live feeds, re-rendering the entire chart on every data tick. With six vehicles updating simultaneously, the dashboard was visibly laggy. We fixed this by heavily throttling the update frequency and memoizing dataset slices per vehicle.
Database Corruption: IndexedDB corrupted itself twice during development. Our first two attempts at offline queue transaction management were flawed in subtle ways that only surfaced under rapid, concurrent writes. We finally solved this by wrapping every operation in explicit transactions with proper abort event handlers.
PWA Cache-Busting: Getting Workbox to actually invalidate cached assets post-deploy was a nightmare. We spent hours dialing in the exact configuration to ensure users wouldn't get stuck on old app versions.
Cross-Browser Sync: The Background Sync API is Chrome-only, which completely broke Firefox offline capabilities. We built a custom fallback using the Page Visibility API that triggers our sync engine whenever a user tabs back into the app.

Accomplishments that we're proud of

The Detection Algorithm: Hussam built the gauge-vs-mileage cross-validation logic from scratch in under 12 hours on night one. The moment it correctly flagged the first simulated theft without a single false positive, we knew this wasn't just a toy project.
The 3 AM Flame Graph Breakthrough: Aneeqa spent two hours staring at React flame graphs trying to find why the UI was dropping frames. Finding the exact Recharts component to memoize was a massive breakthrough—one line of code took the dashboard from choppy to buttery smooth.
Bulletproof Offline Sync: After three complete rewrites, getting the offline queue to cleanly sync 100+ queued entries on a reconnect—with zero silent data drops and explicit conflict logging—felt like a massive engineering win.

What we learned

We learned that offline-first isn't a feature; it’s the product. Real fleet managers can't rely on perfect connectivity, so treating offline data as a first-class citizen changed our whole architecture. We also learned that IndexedDB is incredibly unforgiving with its transaction lifecycles, and that real-world sensor noise is heavy,if your detection algorithms don't account for drift and bumps, false positives will quickly destroy user trust.

What's next for FuelGuard

The detection logic, frontend, and offline queue are complete. Our Node.js/Express backend is staged and production-ready. Our immediate next steps are:

Telemetry API Integration: Swapping manual logs for live CAN bus data via Samsara, Geotab, or Fleetio APIs.
GPS Cross-Validation: Overlaying odometer readings against actual GPS routes to catch "personal trips on company fuel" that raw tank-level monitoring misses.
Live Deployment: Rolling out the fully tested VAPID push notifications and deploying the Firebase Admin/Express stack to a live production server.