# Safety-first walking navigation is unreliable and unsafe
> Source report: https://gapforapp.com/reports/safety-first-walking-navigation-is-unreliable-and-unsafe

## 1. What we're building
Build a “Safety-First Walking Navigator” that ranks and routes walking options using a safety/risk-aware routing layer rather than only fastest-distance heuristics. The must-have experience is a “Zone/Route Safety Score” that changes route choice for walking (especially for night and risk-prone environments), plus a “safety-first routing” mode that avoids dangerous areas even if they are “faster.” The product should explicitly support safety constraints for walking/transit routes and provide a “Safety Mode” so users are not forced to “go in blind” when they can’t verify hazards themselves.

To reduce unsafe guidance while navigating, the navigator must improve reliability and user control: provide a clear option to stop automatic rerouting, ensure guidance matches the on-screen path (including spoken-turn correctness), and add robust confirmation/notification when route changes occur. Because closures and hazards are central to walking safety, include a closure/hazard reporting workflow that supports mode-specific access (e.g., road closed for cars but open for walking/cycling) and adds an appeal mechanism when reports are rejected, with the ability to attach photo proof in the reporting flow. For planning to avoid walking into unsafe dead-ends, also prioritize better walking/transit choices that use transfers and show potential transfers (rather than forcing long walking segments).

Finally, design for low-distraction, accessible wayfinding: offer hands-free capture/voice triggers to reduce manual interaction, and provide safer navigation UI patterns for changing settings or voice guidance (fewer taps, fewer screen changes). Include walking exploration features that help users plan confidently (such as showing district boundaries with different colors, easier drawing of walking routes, and travel-time radius planning), and support accessibility realities (route selection that minimizes stairs and accounts for lift/step constraints where possible).

**Working name:** SafeWalk Navigator
**Tagline:** Safety-first walking routes with Zone Safety Scores, closures by mode, and explicit reroute control.
**Main goal:** Users consistently receive walking routes with clearer safety risk cues and controllable rerouting that match what the app guides.
**Target users:** People who need safer walking directions (including solo travelers, accessibility users, and anyone avoiding unsafe areas).

**Main user result:** Start a walk with a ranked safest route and a Zone/Route Safety Score, then navigate with explicit control over rerouting.
**5-minute outcome:** In the first 5 minutes, choose a walking plan, long-press for 0–100 safety score, preview safety-ranked alternatives, and start navigation with reroute disabled by default.
**What we solve first:** Replace “speed-only walking” with safety-first route ranking plus transparent, mode-aware closures and user-controlled rerouting.
**Out of scope for MVP:**
- Full global coverage for every closure/hazard type in all regions
- Hands-free audio guidance personalization for every accessibility need
- Autonomous real-time hazard detection without user/device verification

## 2. Why this is worth building
- Verdict: **HIGH** (50/100)
- The strongest evidence is the repeated, safety-focused pattern of complaints: unsafe routing choices for walking, mode/closure/access mismatches, and unreliable guidance behaviors (rerouting, wrong turns, location jumps, freezing). Multiple chunks include explicit requests for safety-first walking route selection and safety-mode constraints, plus closure/hazard reporting improvements that prevent routing into dangerous segments. The volume of confirming posts across the corpus is substantial (34), indicating the problem is persistent rather than isolated to one app or scenario. While some posts are tangential, the aggregated feature asks converge on the same core need: dependable, safety-aware route planning and safer user control/confirmation during navigation.

**Current pain:** Users report walking navigation that sends them away from intended routes and can repeatedly fail to agree with the route they indicated. They also feel unsafe when guidance could route into “traffic hell” or incorrect areas.
**Current workaround:** Users zoom out to visually verify the route, cancel the trip and restart if it looks wrong, or try repeated commands until it accepts the intended route. Some avoid reliance on voice/navigation settings that can change unexpectedly.
**Why existing tools fail:** Fastest/standard heuristics ignore explicit safety risk cues and mode-specific access. Guidance reliability gaps force users to self-audit the map (“zoom out”) and cancel reroutes they didn’t explicitly approve.

## 3. Must-have capabilities
- Zone Safety Score (0–100) on long-press map
- Safety-first walking route ranking (downrank dangerous segments)
- Safety Mode routing (avoid dangerous areas even if faster)
- Disable automatic rerouting + explicit reroute confirmation
- Closure reporting workflow with mode specificity (walking vs driving)
- Photo proof attachment when reporting closures/hazards
- Appeal mechanism for rejected closure reports
- Walk Departure/Arrival time set inside phone app

## 4. Use cases & user stories
MVP mobile app that computes a walking “Zone Safety Score” (0–100) and a safety-ranked walking route using incident/closure data. It includes a Safety Mode that avoids dangerous segments, plus an option to disable automatic rerouting and robust notifications when rerouting is requested/confirmed.

- Set walking origin and destination
- Choose Safety Mode before route generation
- Preview alternatives with Safety Scores
- Long-press map for Zone Safety Score
- Start navigation with rerouting controls
- Confirm or stop rerouting during navigation
- Report closure with photo proof (MVP flow)
- Appeal a rejected report

## 5. Pages & form factor
**Form factor:** Safety-first walking navigation mobile app (iOS/Android), with optional smartwatch companion
**Why:** Users explicitly need safer walking routing, mode-specific closures, and in-app time planning without desktop/transit workarounds. A mobile app enables hands-free capture, route start/stop safety controls, and “safest route” selection directly in the environment where they will walk.

### Pages
**5.1 Safety Route Home**
Start a trip quickly and default to safety-first walking behavior with clear safety mode controls.
Key elements:
- Mode selector (Walk / Walk+Transit)
- Destination & origin inputs
- Safety mode toggle (On by default)
- Departure/arrival time picker (in-app)
- Safest-route button and route preview entry point

**5.2 Route Preview & Safety Scoring**
Show risk-aware route alternatives with numeric safety cues before the user starts navigating.
Key elements:
- Map with route polyline candidates
- Overall trip safety score
- Per-segment hazard indicators (where applicable)
- Long-press “area safety score” entry
- Text summary of constraints (e.g., avoids highways, fewer stairs)

**5.3 Walk Navigation**
Provide turn-by-turn guidance optimized for safety-first walking, with rerouting controls and minimal distraction UI.
Key elements:
- Turn-by-turn guidance (audio + visual fallbacks)
- Safety-mode status (On/Off)
- Disable automatic rerouting control
- Route deviation warning (if user goes off route)
- Quick actions (pause/stop/capture note)

**5.4 Walk+Transit Plan**
Produce safer transit plans that minimize walking, stairs, and transfers while keeping guidance mode-aware.
Key elements:
- Transit leg selector / transfers summary
- Lift/elevator availability cues at interchanges
- “Walk to nearest terminal” minimization metric
- Step-by-step walk segments only where necessary
- Next arrival countdowns (for transit portion)

**5.5 Safety Data Sources & Update Cadence**
Build trust by explaining what data drives the safety scores and how it’s updated.
Key elements:
- Data source list (official incidents/police/open data)
- Update cadence display
- What is included/excluded
- User privacy explanation (no rumor/panic posts)
- Feedback link for model gaps

**5.6 Closure & Accessibility Mode Controls**
Handle closures differently by walking/cycling vs driving and prevent users from being routed into wrong-mode closures.
Key elements:
- Closure list segmented by mode (Walk/Cycle/Drive)
- Affected segments on map
- User-visible explanation (“Closed for cars, open for walking”)
- Retry with alternate route if mismatch detected
- User reporting entry (photo proof / appeal when rejected)

**5.7 Capture & Review**
Enable hands-free, safety-friendly capture of notes/tasks during navigation and later review.
Key elements:
- Voice-trigger capture button
- Single “dump everything into one place” inbox
- Timestamped list of captured items
- Attach media within capture-related flows
- Search/filter for past items

**5.8 Settings & Safe Navigation Controls**
Expose safety constraints, rerouting behavior, and device-specific navigation reliability settings.
Key elements:
- Safety-first defaults (locked preferences)
- Toggle: Disable automatic rerouting
- “Fail-safe wrong destination” confirmation requirement
- Android Auto behavior checks (prompt always)
- Stability controls: navigation UI downgrade/fix pathway (if needed)

### Key functions
- **Select safest walking route** *[on: Safety Route Home]*
  - Trigger: User enters origin/destination and taps “Safest route” (or safety mode is default-on)
  - Generates a walking route using safety constraints that downrank dangerous segments even if faster routes exist.
- **Show area safety score on long press** *[on: Route Preview & Safety Scoring]*
  - Trigger: User long-presses on the map
  - Displays a 0–100 safety score for the exact map coordinate/zone under the finger.
- **Compute route safety score from official incidents** *[on: Route Preview & Safety Scoring]*
  - Trigger: User selects a route candidate in the preview list
  - Samples points along the proposed polyline and computes an incident-density risk score using official incident data.
- **Set walking departure or arrival time in app** *[on: Safety Route Home]*
  - Trigger: User opens time picker and selects departure/arrival mode
  - Schedules the walk with user-selected timing inside the phone app (no PC/transit-mode workaround).
- **Remind when to leave based on selected time** *[on: Walk Navigation]*
  - Trigger: User starts a trip with departure/arrival time set
  - Calculates travel buffer and sends “leave now” reminders tied to the selected arrival/departure time.
- **Disable automatic rerouting for safety consistency** *[on: Settings & Safe Navigation Controls]*
  - Trigger: User toggles “Disable automatic rerouting”
  - Prevents background rerouting changes and only allows reroute when user explicitly confirms.
- **Prevent unsafe route edits and impassable tampering** *[on: Settings & Safe Navigation Controls]*
  - Trigger: User attempts to edit roads/mark impassable in the map UI
  - Restricts editing actions that could create unsafe route behaviors and improves data controls for dangerous segments.
- **Show mode-specific closures for walking vs driving** *[on: Closure & Accessibility Mode Controls]*
  - Trigger: Route calculation intersects a reported closure
  - Displays closures with mode specificity so walking/cycling are not blocked by road-closure states intended for vehicles.
- **Capture closure report photo proof** *[on: Closure & Accessibility Mode Controls]*
  - Trigger: User submits a closure report
  - Allows attaching photo proof within the closure reporting flow to strengthen report quality.
- **Appeal when closure reports are rejected** *[on: Closure & Accessibility Mode Controls]*
  - Trigger: User receives rejection result for a closure report
  - Provides an appeal mechanism with the ability to resubmit or add supporting details.
- **Choose safer transit with lift-aware interchanges** *[on: Walk+Transit Plan]*
  - Trigger: User selects Walk+Transit and a route is generated
  - Selects transfer plans that route walking segments through lift-equipped interchanges to minimize stair burden.
- **Display next arrival countdowns for transit planning** *[on: Walk+Transit Plan]*
  - Trigger: Transit leg is selected or user expands transit details
  - Shows next arrival times and recommends departure timing to reduce idle waiting in potentially less safe areas.
- **Avoid highways and unsafe pedestrian segments** *[on: Route Preview & Safety Scoring]*
  - Trigger: User generates safest walking route (Safety mode On)
  - Heavily penalizes or filters walking routes that include highway segments when safer alternatives exist.

## 6. Monetization
**Model:** (unspecified)

## 7. Competitors to beat
| Name | Why it fails | Price | Mentions |
|---|---|---|---|
| Google Maps walking directions (implicitly; used and criticized) | Users describe walking directions sending them far away from the intended straight route, and an Android Auto update producing an unusable overview/bird’s-eye view. Others also report route-length discrepancies between walking vs driving modes. | - | 6 |
| Phone mounts/cradles on wheelchair frame | One commenter flags funding/approval paperwork as a barrier (“a bit of a slog through paperwork and funding”), and another suggests manual hands-free positioning hardware but this may require hardware setup and assistance. | - | 4 |
| Waze | In this chunk, Waze is mentioned as working correctly for underpass routing, but no concrete failure is described; it appears as an alternative comparator. | - | 4 |
| Apple Maps | A user reports Siri-based routing failing to find location; another thread suggests not relying on Siri/Apple Maps due to broader failures (commenter). | - | 3 |
| Google Maps | Users report specific routing/navigation issues (wrong turns, oscillating freeway instructions, and avoiding underpasses even when they expect them to help). | - | 3 |
| Audio prompts / headphones for turn-by-turn navigation | This is suggested as a workaround, but one wheelchair user explicitly says “Audio doesn’t work for me 😬. I need visuals unfortunately,” indicating it may not be universal. | - | 3 |
| Google Maps voice guidance toggling on Android Auto (workarounds via UI/taskbar widgets) | Users report UI changes that make the toggle harder to reach and criticize the safety impact; other users suggest setup-dependent workarounds that may not apply universally. | - | 3 |
| Google Maps (voice search for navigation / routing) | User reports assistant/voice misrecognition and routing to far/incorrect destinations (leading to detours and the need for repeated commands). | - | 2 |

## 8. Distribution
- Top subreddits to launch in: r/GoogleMaps, r/wheelchairs, r/iphone, r/BestofRedditorUpdates, r/AndroidAuto, r/urbanplanning, r/Navigation, r/SubredditDrama, r/travel, r/BORUpdates

## 9. Users & roles
**Primary persona:** Safety-conscious solo walker (incl. mobility/accessibility needs)
**Secondary personas:**
- Transit+walking planner
- Community reporter

**Roles:**
- **End user** — Plan trips, view Safety Scores, start/stop navigation, control rerouting, and submit/appeal closure reports.
- **Reporter reviewer (moderator)** — Approve/reject closure/hazard reports and process appeals (human-in-the-loop for MVP).

## 10. Data model & integrations
- (no data model extracted)

## 11. States
**Empty state:** Home screen shows Safety Mode controls and prompts for start/end while no scores are computed yet.
**Error state:** If scoring or routing fails, the app shows a clear retry action and disables navigation until a safe route can be generated.

## 12. Analytics & metrics
- (not synthesized for this report)

## 13. Risks & open questions
- (no risks/questions extracted)

## 14. Post-launch
- See https://gapforapp.com/reports/safety-first-walking-navigation-is-unreliable-and-unsafe for DM-able hot leads (workarounds × buying intent).
- See https://gapforapp.com/reports/safety-first-walking-navigation-is-unreliable-and-unsafe for verified key quotes you can use as landing copy.

## 15. Suggested build order (3-week MVP cut)
- Week 1: §3 must-haves + §5 page 1.
- Week 2: §5 remaining pages + auth/persistence if needed.
- Week 3: §6 monetization wiring + analytics + launch checklist.

## 16. Setup hints (your stack overrides these)
- `pnpm create next-app . --typescript --tailwind --app`
- `npx shadcn@latest init`
- The agent SHOULD ask the user before committing to a stack.

## 17. How to use this file
You're an AI coding agent reading this in AGENTS.md. Your job:
1. Confirm the stack with the user (their preferences override this file).
2. Scaffold an MVP covering §3 + §5 page-1 first.
3. Defer §6 (monetization) and §14 (post-launch) until §3 ships and works.
4. Re-fetch the live PRD anytime via:
   curl https://painfinder-api.fly.dev/api/public/reports/safety-first-walking-navigation-is-unreliable-and-unsafe/export.json?size=compact

## 18. Verbatim key quotes (top 10)
> "“Is this specific block, hotel, parking spot, or walking route a good idea right now?”"  
> — Safety scoring, post #25730

> "You can long-press anywhere on the map and instantly get a 0–100 safety score for that exact area."  
> — User context safety journey, post #25730

> "the app now looks at reported incidents near your active walking route and gives you a clearer idea of the route’s risk before you start walking."  
> — Safety scoring, post #25730

> "Would a zone score or route safety score actually change how you choose a walking route in SF, or do you mostly rely on instinct and local knowledge?"  
> — Safety scoring, post #25730

> "But I do think it’s useful to have an objective layer when comparing routes, checking unfamiliar neighborhoods, or walking at night."  
> — Safety scoring, post #25730

> "Crime data is imperfect, delayed, and missing context."  
> — Crime data reliability, post #25730

> "Give real potholes the same priority it currently gives to random trash bags."  
> — Surface hazard handling, post #25733

> "Stop overreacting to skid marks, tar snakes, or patches of differently colored asphalt — especially at highway speeds."  
> — Surface hazard handling, post #25733

> "Limit non-critical lane changes to a maximum of two per 60 seconds unless safety requires more."  
> — Road maneuver guidance, post #25733

> "Waiting until 0.2 miles from the ramp and then scrambling across lanes isn’t safe or efficient."  
> — Road maneuver guidance, post #25733

## 19. Manual workarounds users cobble together (top 15)
1. **Accessibility-aware hazard preparedness guidance for sidewalks** — *Carry ice melter/rock salt in a Ziploc bag to regain traction when wheelchair gets stuck/slippery conditions occur.*
   > "I often carry a Ziploc baggie of ice melter or rock salt. It isn't much, but it can give enough traction to get out of a slippery spot like this."
2. **Proactive, user-facing guidance for disabled navigation around unshovelled sidewalks** — *Consider bringing a personal snow shovel to clear path/areas to enable wheelchair movement.*
   > "If I go outside, would bringing my own snow shovel be a good idea?"
3. **Navigation settings troubleshooting / safety-aware routing controls** — *Manually disable a routing preference toggle (“fuel efficient”) to test whether it caused bad route choices.*
   > "I turned off the fuel efficient toggle and will see if that is what broke it."
4. **Navigation app troubleshooting** — *Manually clear app data/cache (and force stop) to address suspected corruption causing bad routing.*
   > "force stop, clear cache and data."
5. **Safety-first route preview / risk detection** — *Manually zoom out and visually verify the route to avoid “bonehead routes.”*
   > "i now have to zoom out just to make sure it isn't sending me into traffic hell or worse."
6. **mode-specific calendar integration and in-app time-setting for walking routes** — *Use a PC to set arrival/departure times for walking; alternatively start in transit mode then switch to walking mode to get the proper trip time before committing it to a calendar.*
   > "Now I have to use the PC to set arrival or departure times for walks, or start in the transit mode then switch over to the walking part to get the proper trip time to be set when I commit it to my calendar."
7. **reliable adherence to user route preferences (e.g., avoid highways) without silent switching** — *After starting, zoom out to inspect the route; if wrong, cancel and restart until the indicated route is used.*
   > "So now, once I press start, I'll take a moment to zoom out to see what the route looks like. If it's wrong, I'll cancel the trip and start over."
8. **sticky route preference / consistency controls** — *Repeatedly cancel and restart navigation until Google follows the user-indicated route.*
   > "Yesterday, I had to cancel my trip FIVE TIMES before Google would finally agree to guide me on the route I indicated."
9. **Offline/app version rollback or safer navigation mode after a faulty update** — *Manually downgrade the app version to restore normal navigation view.*
   > "I forcibly downgraded to 25.46.07 and voila, navigation was back to working normally"
10. **Voice-to-notes/to-do capture app with later review** — *Use a Siri command to set a labeled alarm as a makeshift way to capture tasks hands-free.*
   > "The best workaround I've found so far is asking Siri to set a labeled alarm for a time when I'll be back at my computer"
11. **Automatic fallback/robust UI for navigation after update regressions** — *Revert a problematic version until a fix is available.*
   > "I forcibly downgraded to 25.46.07"
12. **Route correction / 'report bad route' feedback workflow for recurring map detours** — *Set the trip destination so that you can ignore the bad detour; then when you reach home, mark feedback and manually specify what's wrong.*
   > "Every time you drive home, set it as a destination on Google Maps, and ignore the bad detour when you get there."
13. **Recurring hazard-aware route avoidance and persistent fix confirmation** — *Use directions feedback (thumbs down) and select 'Bad Route or Other', then manually type the problem.*
   > "When you get home, give the directions a thumbs down and in the next screen select Bad Route or Other and then manually type in what's wrong."
14. **Persistent POI/road geometry correction for wrong pins/road segments** — *Submit a location change and adjust the pin to the actual end of the driveway; claims it persisted for years.*
   > "I submitted it as a location change and it lasted for years. I put the pin at the actual end of my driveway."
15. **hands-free walking navigation alerts (visual vs audio) for wheelchair users** — *Pre-plot the journey in a maps app, then use a smartwatch for alerts during navigation rather than reading the phone.*
   > "I plot the journey in my preferred maps app and then use a smartwatch (Apple Watch)."

## 20. "I would pay for…" quotes (top 10)
- (none extracted yet — see live report)

## 21. Hot leads summary
- 14 hot leads identified (users who BOTH built a workaround AND signaled buying intent)
- Tier breakdown: 0 hot / 1 warm / 13 cold
- DM-able usernames available at: https://gapforapp.com/reports/safety-first-walking-navigation-is-unreliable-and-unsafe#hot-leads (kept off this file for privacy — see live report)

## 22. Full competitor list (top 10)
| Name | Why it fails | Price | Mentions |
|---|---|---|---|
| Google Maps walking directions (implicitly; used and criticized) | Users describe walking directions sending them far away from the intended straight route, and an Android Auto update producing an unusable overview/bird’s-eye view. Others also report route-length discrepancies between walking vs driving modes. | - | 6 |
| Phone mounts/cradles on wheelchair frame | One commenter flags funding/approval paperwork as a barrier (“a bit of a slog through paperwork and funding”), and another suggests manual hands-free positioning hardware but this may require hardware setup and assistance. | - | 4 |
| Waze | In this chunk, Waze is mentioned as working correctly for underpass routing, but no concrete failure is described; it appears as an alternative comparator. | - | 4 |
| Apple Maps | A user reports Siri-based routing failing to find location; another thread suggests not relying on Siri/Apple Maps due to broader failures (commenter). | - | 3 |
| Google Maps | Users report specific routing/navigation issues (wrong turns, oscillating freeway instructions, and avoiding underpasses even when they expect them to help). | - | 3 |
| Audio prompts / headphones for turn-by-turn navigation | This is suggested as a workaround, but one wheelchair user explicitly says “Audio doesn’t work for me 😬. I need visuals unfortunately,” indicating it may not be universal. | - | 3 |
| Google Maps voice guidance toggling on Android Auto (workarounds via UI/taskbar widgets) | Users report UI changes that make the toggle harder to reach and criticize the safety impact; other users suggest setup-dependent workarounds that may not apply universally. | - | 3 |
| Google Maps (voice search for navigation / routing) | User reports assistant/voice misrecognition and routing to far/incorrect destinations (leading to detours and the need for repeated commands). | - | 2 |
| Tesla FSD (14.2.2.5) | Users report multiple unsafe/reliability issues: pothole avoidance, “Phantom swerves,” “Excessive lane changes,” unsafe “Highway exit planning,” and failure to “Follow the navigation.” | - | 7 |
| zonescout-crime-map-safety (SF safety map tool with zone + route scoring) | This chunk does not claim it fails; it explicitly cautions that it cannot magically determine safety (“Crime data is imperfect, delayed, and missing context.”). | - | 7 |

## 23. Where this conversation lives (top subreddits)
- r/GoogleMaps (31 posts)
- r/wheelchairs (20 posts)
- r/iphone (17 posts)
- r/BestofRedditorUpdates (15 posts)
- r/AndroidAuto (14 posts)
- r/urbanplanning (4 posts)
- r/Navigation (3 posts)
- r/SubredditDrama (2 posts)
- r/travel (2 posts)
- r/BORUpdates (1 posts)