Inspiration

Most navigation platforms focus on one main question: What is the fastest route?

However, when someone is walking or cycling—especially a student or a woman traveling alone—the shortest route may not always feel like the most suitable option. Important context such as the time of day, nearby public activity, poor lighting, isolated areas, uncomfortable crossings, and recent community observations can significantly affect a route decision.

This inspired me to build HerRoute AI, a map-first route comparison platform that helps users look beyond distance and travel time.

HerRoute AI does not claim to guarantee personal safety. Instead, it provides transparent route-condition insights that help users make a more informed decision based on the available data.

What it does

HerRoute AI allows users to enter a destination, use their current location, and generate walking or cycling route options.

The platform can:

  • Generate real route alternatives using geocoding and routing data.
  • Compare routes by distance, estimated duration, and surrounding conditions.
  • Calculate a transparent Route-Condition Score from 0 to 100.
  • Recommend a route while considering both its score and additional travel time.
  • Explain why a route received its score using AI-generated, human-readable insights.
  • Display weather information for additional travel context.
  • Show verified community reports on the map.
  • Allow registered users to submit location-based reports such as poor lighting, harassment, obstructions, isolated areas, crowding, or unsafe crossings.
  • Allow administrators to verify, resolve, reject, and audit community reports.
  • Let users create accounts, verify their email, save routes, manage preferences, and review their submitted reports.
  • Support both English and Arabic, including right-to-left layout.
  • Support walking and regular cycling routes.

The score is a decision-support indicator, not a probability and not a guarantee that a route is safe.

How I built it

I built HerRoute AI as a full-stack browser-based web application.

The frontend was created using HTML, custom CSS, Tailwind CSS utilities, and vanilla JavaScript. I used Leaflet with OpenStreetMap to display the map, route geometry, destination markers, current location, and verified community reports.

The backend was built using Python and Flask, with a modular architecture separating API routes, business services, external providers, security controls, and database models.

Geoapify provides destination geocoding, route generation, distance, duration, route geometry, and nearby-place information.

I created a deterministic Safety Engine that calculates the route-condition score using five weighted factors:

  • Estimated lighting conditions
  • Nearby public activity
  • Nearby public and support places
  • Verified community reports
  • Time-of-day conditions

The score is calculated using transparent rules. It is not generated by the language model.

Groq is used only after the score has been calculated. It converts the route metrics into a structured explanation and answers questions using the available route context. This separation prevents the AI model from silently changing or inventing the numeric score.

Open-Meteo provides current weather information. Weather is presented as travel-comfort context and is not currently included in the Safety Score.

I used PostgreSQL with SQLAlchemy and Alembic to store accounts, hashed authentication tokens, saved routes, community reports, and moderation history.

Redis is used to store distributed rate-limiting counters. The project also includes CSRF protection, CORS configuration, secure-cookie options, security headers, structured logging, health checks, database migrations, Docker Compose configuration, Gunicorn configuration, and deployment scaffolding for Render.

Challenges I ran into

One of the biggest challenges was designing a score that was useful without creating false confidence. Personal safety cannot be reduced to a perfect number, and route data can be incomplete or outdated. I addressed this by using transparent factors, neutral fallback values, evidence-coverage indicators, and clear disclaimers.

Another challenge was separating deterministic analysis from generative AI. I wanted AI to make the results easier to understand, but I did not want an AI model to invent safety information or control the score. The final architecture calculates the score first and gives the AI only the structured results it needs to explain.

Integrating several external services was also challenging. Routing, nearby places, weather, map tiles, email, and AI can each fail independently. I added error handling and graceful fallback behavior so that, when possible, one unavailable service does not break the entire route-planning experience.

Community-generated data created additional moderation and privacy challenges. New reports begin as pending and must be reviewed before appearing as verified public evidence. Public responses also exclude the reporter’s identity.

Building a bilingual interface introduced challenges related to Arabic translation, dynamic content, and RTL layouts. I implemented language and direction switching while keeping the map and interactive components usable across both languages.

Accomplishments that I’m proud of

I am especially proud that HerRoute AI grew beyond a simple interface prototype into a substantial working MVP with real routing, persistent data, authentication, moderation, AI explanations, and security controls.

Some of the accomplishments I am most proud of include:

  • Building a transparent scoring engine instead of relying on an unexplained AI-generated number.
  • Keeping the AI explanation layer separate from the numeric scoring system.
  • Integrating real walking and cycling routes rather than using static or fake route data.
  • Creating a complete community-report workflow with pending, verified, resolved, and rejected states.
  • Building an administration system with moderation history and audit events.
  • Implementing account registration, email verification, password reset, saved routes, user preferences, and account deletion.
  • Supporting both Arabic and English.
  • Designing the project with privacy, security, and responsible safety language in mind.
  • Creating deployment, migration, monitoring, backup, and testing foundations for future development.

What I learned

This project taught me that responsible AI is not only about choosing a model. It is also about deciding what the model should and should not control.

I learned that important numeric decisions should be explainable, reproducible, and independently testable. AI can then provide value by translating structured results into understandable language.

I also learned that community data requires more than a submission form. It needs authentication, moderation, privacy controls, status tracking, audit records, and clear rules about how the information affects the product.

From a technical perspective, I gained experience connecting frontend map interactions with Flask APIs, external routing and weather providers, PostgreSQL persistence, Redis rate limiting, authentication workflows, bilingual UI behavior, and production-oriented configuration.

Most importantly, I learned that building a socially impactful platform requires careful communication. HerRoute AI must help users understand available route conditions without promising that technology can guarantee their personal safety.

What’s next for HerRoute AI

The next step is to move from a local MVP to a carefully controlled online pilot.

Future improvements include:

  • Conducting usability testing with students, pedestrians, cyclists, and women who regularly travel alone.
  • Improving the scoring model using better-quality local datasets and user research.
  • Adding stronger community-report validation and duplicate-report detection.
  • Improving privacy through report-coordinate fuzzing or area-based aggregation.
  • Adding stronger moderation roles, abuse prevention, and administrator security.
  • Expanding automated browser, accessibility, security, and load testing.
  • Improving Arabic localization and screen-reader accessibility.
  • Adding retry and caching strategies for external service failures.
  • Testing backup restoration and production monitoring.
  • Exploring real-time navigation and additional transportation modes.
  • Publishing clearer evidence and confidence indicators for every recommendation.

The long-term goal is not to replace existing navigation applications or emergency services. It is to provide an additional, transparent layer of route-condition awareness that helps people make more informed travel decisions.

Built With

Share this project:

Updates