TrailSafe

Sign-in
Sign-up
Search-hike
Safety
set-up-emergency
hike
end-hike

Inspiration

TrailSafe started with a question that many women ask before heading into the outdoors alone alone: will I actually feel safe on this trail today? Not “is the route doable". For women who hike, trail run, or explore in urban–nature transition zones (like Vancouver + the North Shore), safety isn’t just about fitness or route difficulty; it’s also about isolation, uncertainty, and connectivity gaps. Existing apps are excellent at trail discovery and navigation, but they rarely answer the real-time, confidence-building questions: but whether the conditions, timing, and isolation risk would make the experience stressful or uncertain.

The idea evolved into a safety-first hiking companion that reduces uncertainty with clear context. Instead of trying to solve everything, the goal was to design an MVP that gives a user confidence providing solutions to these three questions: (1) is this trail safe with the current weather conditions? (2) What if I lose signal, will I be able to find my way back? And (3) If something goes wrong, will anyone know?

What it does

TrailSafe is a React Native + Expo app that centers the experience around a Trail Safety Dashboard, where users can quickly evaluate whether to start the hike. The dashboard surfaces live conditions (weather and sunset timings), and reported hazards on trail (within the past 48 hours). It then feeds this information to Gemini with a standard prompt to calculate a score on a scale of 1-10. This score is displayed to the user as a single Safety Score to give an idea of the perceived safety of the trail before starting it, while you still have service.

The user is also prompted to set up a timed check-in feature, where they set an expected return time and an emergency contact. If the check-in expires, the app moves into an overdue state and notifies a trusted contact on the most recent known location from the recorded breadcrumb path, while the user is still online.

Once the hike starts, the app switches into an active session mode that records a (aforementioned) breadcrumb trail using GPS. This is intentionally designed to be offline-first: the app continues collecting coordinates and rendering the route for the user even when the network drops. If the user runs into a hazardous obstruction on the trail, they can report it immediately, so that for any other user planning to hike the trail receives an updated safety score based on that information.

How we built it

The app was built with React Native + Expo using TypeScript for predictable state and safer integrations. We leaned on a design pipeline powered by Lovable for rapid interface iteration and layout consistency, and used Gemini AI to calculate safety score. The goal was to make the safety experience feel empowering and transparent.

Trail search and mapping were implemented with the Google Maps API. Map rendering is central to the “breadcrumb” experience: while hiking, the app continuously appends new GPS points to an in-memory polyline and persists them locally so the user can still navigate even if connectivity disappears. Weather conditions were pulled from a Weather API so the Safety Dashboard reflects current weather conditions on the trail. We send trail context (difficulty, distance), live weather, hours until sunset, and the last 48h hazard count to a Gemini model via OpenRouter. The prompt weights hazards most heavily, then sunset proximity and weather, with smaller difficulty/distance impact. Then Gemini returns a JSON {score, label}, which replaces the local mock safety score shown on the Trail details screen.

For persistence and future scalability, we used Supabase to add users, hikes, reporting hazards on trail, and check-in sessions. Even though the hackathon MVP could run with a lightweight application, wiring the Supabase data model early meant the system architecture stays realistic and evolvable.

At a high level, the system is organized around a few clean boundaries. The UI layer handles navigation, map display, and real-time hazard and users location updates. A service layer manages integration concerns such as Weather API calls, Google Maps abstractions, and Supabase queries. A scoring module computes an interpretable Safety Score.

Challenges we ran into

Limited access or no access to trail APIs, thus resorted to using Google Maps API for now. For future iterations can scrape data from Trailforks or AllTrails, or mimic the OSM derivative methodology used by AllTrails.
We faced problems finding an API to automate the email security check-ins through our service. Most services required approval, or only provided a limited trial version. In the end we decided to go ahead with the trial version of Postmark.
GPS jitters make polylines look messy
Syncing changes to Figma UI and the frontend code for application

Accomplishments that we're proud of

We’re proud that we delivered a working end-to-end MVP that feels like a real safety product rather than a loose concept. The app has a coherent flow from “decide if I should start” to “track me while I’m out there” to “escalate if I don’t return,” which makes it easy to understand and follow. Building a safety tool is as much about clarity as it is about features, and we’re proud the UX stayed focused on confidence instead of fear.

We’re also proud of the technical integration work, especially the way we connected multiple services into a single pipeline without the app feeling fragile. We successfully combined Google Maps for trail visualization, a Weather API for live conditions, Supabase for persistence, and Gemini for structured scoring output.

Finally, we’re proud of the offline-first breadcrumb experience. Even with limited time, we built a hiking session mode that continuously appends GPS points into a polyline and persists them locally so the map experience remains useful when connectivity drops. That piece made the product feel grounded in a real outdoor constraint rather than a purely “online” demo.

What we learned

We learned that outdoor safety apps have to be designed around failure states first. TrailSafe only works if it still provides value when service drops, permissions are limited, or an API call fails, so we had to think carefully about local state, GPS sampling, and graceful fallbacks in the UI rather than assuming everything is always online.

We also learned that if AI is producing something a user will rely on, it needs structure. Instead of letting Gemini return free-form text, we constrained it to a predictable output schema {score,label} based on explicit inputs (trail context, weather, hours until sunset, and hazard count). That made the scoring component easier to integrate, debug, and consistently display.

Finally, we learned how to use AI to build first version UIs that can be iterated on.

What's next for TrailSafe

Next, we want to replace our “best-effort” trail data. During the hackathon we relied on Google Maps because we didn’t have reliable access to dedicated trail APIs, but future iterations would pull richer trail metadata by scraping sources like Trailforks or AllTrails, or by mimicking the OSM-derivative approach that platforms like AllTrails use. That would let us score trails using more than just basic route context and user-reported hazards.

We also want to harden the check-in notification system. We ran into API limitations (approvals and restrictive trials), so we used Postmark’s trial to demonstrate email alerts, but the next step is to add more reliable messaging options (including SMS) and move overdue triggering to a backend workflow so notifications can send even if the client isn’t active.

On the hiking session side, we’d improve the breadcrumb path quality by smoothing GPS jitter and filtering noisy points so the polyline looks clean and trustworthy in real conditions. Finally, we’d tighten the design-to-code workflow by building a more systematic Figma-to-React Native handoff (shared components, consistent spacing tokens, and a clearer UI system) so UI iterations don’t create friction during development.