JalanAman

Logo
Tutorial Video
SOS
Contact
Route
Dashboard

Inspiration

Late-night walks home from a bus stop or ojol drop-off point are a daily reality for students and workers across Indonesia and so is the informal knowledge of "which street to avoid after dark" that circulates only through word of mouth or scattered WhatsApp neighborhood groups. A regular map app will happily route you through the fastest path, but it has no idea that path is unlit and has had three reported incidents in the last month. We wanted to put that informal safety knowledge on the map, literally and give people a way to call for help that doesn't depend on anyone else installing anything first.

What it does

JalanAman is a community-powered safety companion with five core pieces:

Safety map - crowd-sourced pins for poor lighting, crime-prone spots, and accident hotspots, shown around the user's current location.
Quick report - one tap, pick a category, auto-geolocation, no account needed.
Route score - enter a destination and get an "Aman / Waspada / Hindari" (Safe / Caution / Avoid) score layered on top of routes computed by OSRM, our self-hosted open-source routing engine.
SOS button - a 3-second cancellable countdown, then a loud local alarm + vibration that works even offline, plus an automatic email and a one-tap pre-filled WhatsApp message to emergency contacts.
Emergency contacts can also use MacroDroid to automatically play a loud alarm or notification sound whenever the SOS email is received, helping ensure the alert is noticed immediately.
Web dashboard - a read-only heatmap for RT/RW (neighborhood watch), campus security, or local police to see risk hotspots in their area.

How we built it

The backend is Rust (Axum + Tokio) exposing a REST API over PostgreSQL 16 (using the earthdistance extension for radius queries) with Redis used for lightweight caching and rate-limiting. The frontend is Dioxus, compiled to WebAssembly and shipped as an installable PWA rather than a native mobile app, a deliberate choice to keep the build loop fast within a 30-hour window. Maps are rendered with MapLibre GL JS on top of OpenStreetMap tiles, routes come from our own OSRM instance (self-hosted via Docker, running against a regional OSM extract), and destination search uses Nominatim for geocoding, a fully open-source mapping stack instead of a paid Google Maps API. For the SOS feature, emails go out through a transactional email API (Resend/SendGrid), WhatsApp messages are pre-filled deep links generated by the backend, and recipients can optionally configure MacroDroid to trigger a custom alarm when the SOS email arrives. The whole stack runs locally and in production via Docker Compose so every team member had an identical environment from hour zero.

Challenges we ran into

Our biggest challenge wasn't technical it was scope discipline. Our first design for the SOS feature used Web Push (VAPID) notifications, which meant emergency contacts had to install the PWA and grant notification permission before an emergency ever happened. Halfway through planning we realized that was a real adoption barrier, so we redesigned it around email + WhatsApp instead, which needs zero setup from the contact's side. We also had to be upfront with ourselves that no third-party app can truly "force" an alert past a phone's silent mode that requires special OS-level entitlements we couldn't obtain in a hackathon. Instead, we relied on a local, offline-capable alarm as the guaranteed alert on the sender's device, while email and WhatsApp act as best-effort notification channels. For contacts who want a louder notification, they can optionally configure MacroDroid to detect incoming SOS emails and play a custom alarm, although this still depends on the phone's notification behavior and user settings. Rust's compile times and Dioxus's newer ecosystem also meant slower iteration than a more common stack would have given us, which pushed us to cut a custom routing engine entirely in favor of scoring on top of an existing routing engine rather than writing pathfinding ourselves. Choosing a fully open-source mapping stack (OpenStreetMap + MapLibre + self-hosted OSRM) instead of a paid Google Maps API meant we had to budget real time for processing an OSM regional extract into an OSRM routing graph before the route score feature could work at all a step that's easy to underestimate if you leave it for later in the timeline.

Accomplishments that we're proud of

A complete, working SOS flow end-to-end: cancellable countdown → local alarm → automatic email → one-tap WhatsApp, with optional MacroDroid integration for louder email alerts on the recipient's device, and honest handling of edge cases like no internet, no GPS, and no saved contacts.
A consistent dark/light design system across every screen, built around the idea that one color should always mean one thing (red = danger, amber = caution, green = safe).
Keeping the whole app to 3 navigation tabs with no login system at all, while still covering five real features.

What we learned

We learned to catch ourselves overclaiming early "force alert" sounds great in a pitch but doesn't survive a technical Q&A, and reframing it honestly (local alarm = real-time guarantee, email/WA = best-effort, optional MacroDroid automation = enhanced notification for recipients) actually made the product easier to explain, not harder. We also learned Rust's Axum and Dioxus in a real time-boxed setting, and picked up a healthy respect for how much a tech stack choice affects what's actually achievable in 30 hours.

What's next for JalanAman

Exploring native mobile builds with proper critical-alert permissions where platform policy allows it
Formal partnerships with RT/RW, campus security offices, or local police to pilot the dashboard
Auto-dial as an additional SOS channel
Community moderation tooling beyond simple upvote/downvote thresholds