Building SafeNav was an ambitious journey that pushed us beyond simple CRUD operations into complex algorithms and AI integration. Here are the major hurdles we faced and how we overcame them:

The "Safest vs. Shortest" Algorithmic Dilemma
The Hurdle: Initially, our focus was purely on finding the safest path. However, our mentor challenged us: a safe path is useless if it takes 3 hours for a 20-minute trip. We needed to balance safety with efficiency.
The Solution: We implemented a custom Dijkstra’s Algorithm. Instead of standard distance weights, we created a composite "Edge Weight" formula. This formula mathematically weighs distance against flood risk and rain intensity. This allowed the system to find the "sweet spot"—a route that is significantly safer but not unreasonably longer.

Data Scarcity & Quality
The Hurdle: Finding a high-quality, real-world dataset for urban flood prediction was incredibly difficult. Public sensor data is often sparse or unstructured.
The Solution: We had to compromise and adapt. We sourced a "good enough" dataset from Kaggle to train our initial models. While not perfect, it allowed us to build a robust ML pipeline (ml_prep.ipynb) that can easily be retrained once better, localized data becomes available.

Testing "Rain" on a Sunny Day
The Hurdle: Our system relies on live weather data from the OpenWeather API to trigger warnings. Testing the "Monsoon Mode" features was difficult when the actual weather outside was clear and sunny.
The Solution: We had to build a robust testing environment where we could manually inject or mock weather parameters. This ensured our risk assessment logic worked correctly regardless of the actual forecast outside.

Infrastructure Costs vs. Hackathon Constraints
The Hurdle: Our mentor suggested adding a crowdsourcing feature where users upload images of hazards. However, cloud storage solutions (like AWS S3 or Cloudinary) usually require credit cards or paid tiers, which wasn't feasible for us.
The Solution: We engineered a local file storage system within our FastAPI backend. We save uploaded images directly to a local uploads/ directory and Firestore Database contains all the texts and serve them via static file mounting. This proved the concept perfectly without incurring infrastructure costs.

Moving from Hardcoded to Generative AI
The Hurdle: We initially hardcoded the "Severity Reasons" (e.g., "Risk is High because X"). It felt robotic and didn't account for complex combinations of factors.
The Solution: We integrated Google Gemini AI. Now, we pass the environmental parameters to Gemini, and it generates a dynamic, natural-language explanation of why a specific area is risky. This made the app feel much more intelligent and user-friendly.

Expanding the Scope of Hazards
The Hurdle: We started with just waterlogging. Our mentor pushed us to make it a complete safety app by including potholes, accidents, and road blockages.
The Solution: This required refactoring our database schema and frontend reporting forms. We created a flexible "Hazard Type" system that allows the map to render different icons and risk weights depending on whether the issue is a flood or a car accident.

The UI Challenge: Interactive Route Selection
The Hurdle: One of our biggest technical blockers was the map UI. We wanted to show multiple route options (e.g., "Route A: Fast but Risky" vs. "Route B: Safe but Slow") and let the user click to choose one.
The Outcome: Managing the state for multiple interactive GeoJSON layers in Leaflet proved to be extremely complex. While we successfully visualized the routes, making them fully interactive and selectable was a UX challenge we are still refining. It taught us a lot about the limitations of mapping libraries and state management.