Imagine this:
You land in Rio at 11PM, solo, tired, and slightly paranoid.
Instead of opening 10 tabs on TripAdvisor, Google Maps, and Reddit…
Yo...
For further actions, you may consider blocking this person and/or reporting abuse
This seems like a really interesting and useful idea.
I just wanted to clarify this -
Suppose a person has an intended destination X and has to go through a certain set of places like A, B, C to reach there. So will all those places and X be what is available in the swipe feature? As in, what is the user actually going to swipe on? Is it based on the route?
Great question — and I probably didn’t explain this clearly in the post.
The swipe isn’t route-based (A → B → C → X).
It’s context-based discovery.
So users are swiping on:
• Places (destinations, neighborhoods, spots)
• Experiences (e.g., “morning beach walk,” “night market”)
• Situational cards (e.g., “safe airport transfer,” “areas to avoid tonight”)
In your example:
If someone wants to go to X, the app would show:
Cards for X (destination insights)
Cards for nearby areas (A, B, C if relevant)
Possibly a separate “how to get there safely” card
But not a strict step-by-step route in swipe form.
Navigation itself would still rely on a map — the cards are more about:
“Where should I go / avoid?”
“When and how should I go?”
I’m also thinking about eventually layering in route-aware safety hints, but probably not in the swipe flow (might get overwhelming).
Would be curious if a route-based swipe experience would actually feel useful or just confusing.
This makes sense now, thankss :)
My next concern is ranking. If the feed mixes places, experiences, and alerts, how do you decide what shows first?
Because ordering, personalization, and relevance seem critical here - someone landing at night may need safety/transport first, while a daytime tourist may want experiences.
the UX is clean but I'd push back on the data layer - safety conditions change constantly. a card marked 'avoid after 9pm' from 6 months ago is worse than no card. how do you handle data freshness?
This is a really fair pushback — stale safety data is actually worse than no data.
The way I’m thinking about it is to treat safety as time-decaying, not static:
• Every data point has a timestamp + decay function (older inputs lose weight quickly)
• Cards surface “last updated” + confidence level instead of fixed statements
• If data is too old → the card shifts into a “low confidence / research mode” instead of showing strong guidance
For example, instead of:
“Avoid after 9PM”
It becomes:
“Previously flagged for late-night incidents (last confirmed 6 months ago — low confidence)”
Long-term, I’d want:
• Real-time user reports (with rate limits to prevent spam)
• Possibly external signals (events/news)
• Auto-expiry of safety flags unless reconfirmed
So the system errs on uncertainty over outdated certainty.
Still very much an open problem — if you’ve seen good patterns for handling freshness in similar systems, I’d love to learn from that.
the decay function is the hard part — half-life varies wildly by neighborhood. some blocks shift week to week; others are stable for years. i’d probably lean on crowdsourced re-verification triggers over pure time-based decay. did you consider letting users flag staleness directly?
That’s a great point — a fixed decay model probably oversimplifies something that varies a lot by location.
I really like the idea of crowdsourced re-verification. Instead of just time-based decay, I’m thinking of introducing a “needs revalidation” state where older cards lose confidence and prompt users to confirm if the info is still accurate.
Letting users directly flag something as outdated also makes sense. That could reduce confidence, weaken strong claims, or trigger a re-check loop rather than relying purely on time.
Feels like a better approach is combining light decay with active revalidation instead of trying to model freshness only through time.
the "needs revalidation" state makes sense - softer than full expiry, more honest about uncertainty. the real question is what triggers it. time threshold is reliable but dumb; field signal is smarter but only works if someone shows up to send it.
Yeah, that tradeoff makes sense.
I’m leaning toward a hybrid trigger:
The 'Tinder-style for travel safety' framing is interesting but I'd push back on one thing: swipe-based UX optimizes for fast judgment, while safety decisions usually benefit from slow, deliberate evaluation. The two might be in tension. Have you considered a different signal pattern — maybe a bookmark-then-review flow, or surfacing safety scores prominently before the swipe rather than after? Curious how user testing has played out so far. Also, where's the ground truth for safety data coming from? That's usually the hardest part of building anything in this space.
This is a really insightful point — and honestly something I’m still figuring out.
You’re right that swipe UX encourages fast decisions, while safety probably needs deliberation. My current thinking is:
• Swipe is just for triaging options (save / skip)
• The actual decision happens after tapping into a card
• Safety signals (score, alerts, recency) are visible before the swipe, not hidden behind it
So ideally:
Swipe = “Is this worth considering?”
Tap = “Is this actually safe for me?”
That said, I’m definitely exploring alternatives like:
• Bookmark-first → review later
• Or forcing a quick “safety summary” before allowing a save
On ground truth — agreed, that’s the hardest part.
Right now I’m thinking of a hybrid approach:
• User reports (with weighting + history)
• Verified local contributors (not absolute authority, but higher signal)
• Recency + frequency of incidents
• Eventually external datasets where possible
But I’m trying to avoid presenting anything as absolute truth — more like confidence-weighted signals.
No real user testing yet beyond mock flows, so this is still very much in the hypothesis stage.
Really appreciate this — it’s exactly the kind of tension I need to resolve early.
who decides which area is dangerous?
Great question — and honestly one of the hardest parts of this idea.
The goal is that no single person “decides” an area is dangerous. It would be a combination of signals:
• Aggregated user reports (e.g., recent incidents like pickpocketing)
• Local contributors with verified history (weighted higher, but not absolute)
• Recency-based data (something unsafe last night ≠unsafe all the time)
• External signals (news/events where possible)
So instead of labeling a place as “dangerous,” the app would try to show context like:
-> “3 incidents reported in last 48 hours”
-> “Safe during daytime, avoid late night”
The idea is to avoid permanent labels and focus on time-sensitive, situational awareness.
Still figuring out how to prevent bias or misuse here — would love your thoughts on how you’d approach this.
Definitely could be helpful. Would need a lot of nuance as to not pigeonhole certain neighborhoods etc I'd imagine.
That’s a really important point — and something I’m trying to be very careful about.
The last thing I want is to label entire neighborhoods as “unsafe” and reinforce stereotypes. The intention is more about micro-context rather than blanket judgments.
For example, instead of:
->“This area is dangerous”
It would be:
-> “Safe in the morning, avoid after 9PM”
-> “Reports of phone snatching near this specific street recently”
So it’s less about pigeonholing places and more about situational guidance + timing + exact spots.
I’m also considering:
• Decaying old data so places aren’t permanently flagged
• Showing confidence levels instead of absolute statements
• Separating “perception” vs “recent data”
But yeah, this is a delicate balance — if handled poorly it could do more harm than good.
Really appreciate you calling that out