Building the Waikīkī Smart Dashboard – Architecture Decisions & This Week’s Wins

This week I made serious progress on the Waikīkī Smart Dashboard — the project I’m building to track and summarize real-time traffic and local events in Waikīkī. It’s not just a cool concept — it’s teaching me a ton about software architecture, APIs, and designing for real-world users (including myself).

🧱 Project Stack & Architecture

From the start, I knew I wanted this project to be more than a front-end demo. It’s built to scale, to integrate with real data sources, and to give users a clear snapshot of what’s happening in Waikīkī — all without relying on expensive third-party tools.

Tech stack:

  • Backend: FastAPI (Python)
  • Frontend: React with TailwindCSS
  • Map layer: MapLibre GL with custom overlays
  • Data sources: TomTom Traffic API, Honolulu construction/event feeds, and OpenAI/LLaMA 3 summaries
  • Deployment: Local dev for now, aiming for a containerized public setup

A core goal this week was keeping the architecture modular and async-friendly. I’m balancing real-time API fetching, background LLM summaries, and responsive UI updates — without letting any one part bottleneck the others.

⚙️ Highlights From This Week

  • ✅ FastAPI backend serving structured traffic incident data
  • ✅ Dynamic summaries powered by OpenAI (testing LLaMA 3 soon)
  • ✅ Built a base map overlay with live incident points
  • ✅ Early support for predictive layers (recurring rush hour, school traffic, and construction data)

This is more than just a project — I’m designing the backend like a product. Clean endpoints, flexible models, and potential reuse for future tools I build.

💡 Design Philosophy

Waikīkī is chaotic — traffic, sirens, events, tourists, locals, detours. My dashboard should cut through the noise and surface useful info fast.

Core UI goals:

  • Lightweight layout, mobile responsive
  • Summaries that are casual, quick to skim, and actually helpful
  • Filterable map layers (by time, type, severity)
  • Early warning system for avoidable delays

Instead of dumping raw traffic logs, the dashboard tells you: what’s happening, is it bad, and should I avoid it?

🧠 What’s Next

Here’s what I’m lining up next:

  • Add historical data to train traffic prediction logic
  • Build an admin panel to manage summaries, incidents, and API keys
  • Test LLaMA 3 locally and swap it in for OpenAI
  • Start public deployment (maybe Fly.io or Railway)

This is already the most technically and personally rewarding thing I’ve built. Every decision — from how I model the incident data to how I summarize it — pushes me further as a software engineer.

Mahalo for reading! If you're into civic tech, local dashboards, or building your own platform from scratch — I’d love to connect.