Why I Gave Up on Fancy APIs and Built My Own Island-Aware Traffic Dashboard

Why I Gave Up on Fancy APIs and Built My Own Island-Aware Traffic Dashboard

When I first started building the Waikīkī Smart Dashboard, I figured it would be straightforward: hook into a few traffic APIs, pull some live data, drop it on a map, done.

But that plan didn’t last long.

Most APIs either gave me stale data, blank results, or required paid tiers that didn’t make sense for a solo developer working on a student project. Worse, almost none of them actually understood what was going on in Hawaiʻi. Rush hour could be in full swing, and the API would return nothing.

So I stopped trying to make everything plug-and-play and started building the core logic myself.

Where the API Plan Fell Apart

I tried just about everything:

  • TomTom worked technically, but consistently returned empty incident lists for Oʻahu — even when I knew traffic was jammed.
  • HERE Technologies has a solid offering on paper, but the dashboard wouldn’t load on my machine, and live congestion data wasn’t easily accessible.
  • Mapbox looked great visually but didn’t offer real congestion or incident data.
  • INRIX IQ had useful analytics, but no public API unless you were part of a larger enterprise partnership.
  • Radar and TravelTime were interesting for geofencing and isochrones but didn’t solve the core problem: getting live, local traffic insights.

What became obvious was that these services are built for the mainland. They rely on data partnerships that don’t always reach Hawaiʻi, and when they do, it’s often incomplete or delayed.

The Pivot: Build Around Local Data First

After hitting enough dead ends, I stepped back and reframed the project.

Instead of trying to find a perfect global traffic API, I focused on what I could control: publicly available, local-first data sources. I started pulling from:

  • The City & County of Honolulu Open Data API, which includes roadwork alerts and scheduled closures
  • PDFs from the Hawaiʻi DOT, parsed with pdfplumber to extract lane closure schedules
  • (In progress) Local news sources, to scrape headlines for real-time incidents or flooding alerts

With that shift in thinking, the project started to click. Rather than depending on a single service to tell me what was happening, I began thinking like a systems engineer: collect multiple streams of local data, normalize them, and generate my own interpretation.

System Design: From Static Data to a Smarter Summary

The dashboard evolved into something more layered:

  • FastAPI powers the backend, fetching and combining local and global sources
  • Mapbox or LibreMap handles the map rendering
  • Preline + Tailwind gives me a flexible component system for organizing views
  • Groq’s LLaMA 3 writes a short, human-style summary of the day’s traffic and alerts

That last part became more important than I expected. Once I had multiple sources feeding in, I needed a way to translate raw data into something clear and useful. LLaMA 3 turned out to be a perfect fit — but I had to tune the prompt carefully.

At first, it sounded like a corporate travel brochure. So I rewrote the system prompt to cut the tourist lingo and reflect how people actually talk here. Something closer to, “No major slowdowns through town today. Construction still going on by Ala Moana — watch for lane shifts.” That voice made the dashboard feel grounded in place, not outsourced.

Expanding the Scope: From Waikīkī to Oʻahu

Originally, I wanted to focus just on Waikīkī. But as I started mapping the incidents and pulling roadwork data, I realized that only telling part of the story wasn’t enough.

Closures in Kaimukī, traffic near the H-1 split, roadwork in Kāneʻohe — it’s all connected. If someone’s commuting across the island or navigating around construction, they need to see the bigger picture.

Now, the dashboard covers all of Oʻahu, and I’m building with future expansion in mind.

Final Thoughts

I didn’t expect this project to turn into a mini data pipeline — but I’m glad it did. Building custom logic forced me to understand not just how data flows, but how people read and rely on it. It’s not just about putting points on a map. It’s about offering clarity.

This approach wasn’t the easiest technically, but it gave me something most plug-and-play APIs couldn’t: trust in the data and control over the experience.

Sometimes, the best architecture isn’t about the tools you integrate — it’s about the assumptions you stop making.