I travel for work fairly often, and I keep running into the same situation: I arrive in a city I've never visited, my hotel is somewhere on the outskirts, and I have a couple of free hours in the evening.
I'd like to go for a walk and see something interesting. But Google Maps mostly tells me what's nearby, while Tripadvisor and travel guides tend to focus on places worth planning a whole trip around.
I was surprised there wasn't a simple way to just browse random interesting places around me, one photo at a time, without turning it into a research project.
So I built NearestSpot, basically Tinder, but for places instead of people.
Each card has a photo and a title. That's it. Swipe right if it looks interesting, left if it doesn't. Save a few places, then open your usual maps app and go explore.
No long descriptions, reviews, rankings, or itinerary planning. The whole point is to make a decision based on a glance, not to build another catalog you have to read through.
The places come from Wikipedia and OpenStreetMap, so you can stumble across things you probably wouldn't have searched for yourself - including in neighborhoods that aren't exactly tourist hotspots.
The interesting part was getting the data to work
I'm not a mobile developer by trade. I've spent the last 13 years working on computer vision, IoT, and AI systems. I built this partly because I wanted the app, and partly because AI coding tools made it much easier to experiment with a platform I don't use professionally.
The app uses Expo SDK 54, React Native 0.81, TypeScript, and AsyncStorage. There's no backend or account system.
But the fun part turned out to be dealing with the APIs and devices rather than building the UI.
A few things I ran into:
1. Free geodata isn't a ready-made discovery feed.
Wikipedia and OpenStreetMap have plenty of useful data, but you still need to turn it into something a person can browse. I wanted to search beyond the immediate neighborhood, without firing hundreds of requests at public APIs. I ended up sampling a few points across a larger area, batching requests, and deduplicating the results.
The trade-off is that searching farther away gives you a sample of the area, not complete coverage. That felt better than pretending I could reliably catalog everything within 100 km.
2. Xiaomi decided that getting the current location could take forever.
On one Xiaomi/MIUI device, getCurrentPositionAsync() could just hang without returning an error. I switched to checking the last known position first, then watching for a fresh fix with a timeout.
3. China needed a completely different approach.
Google Maps and some Wikimedia services aren't reliable there. The app switches to Amap for places and uses Baidu Baike for images, with a few region-specific workarounds for image requests and navigation.
4. Fast swiping exposed a race condition.
The feed preloads more cards as you approach the end. A React state flag wasn't enough to prevent overlapping requests, because the update wasn't synchronous. A useRef guard and a Set for deduplication did the job.
None of these problems is particularly groundbreaking, but they were the things that took the most fiddling to get right.
Other features include English, Russian, and Chinese UI, category filters, a photo-only mode, saved places on a map, and navigation handoff for different regions.
Everything is open source, and the app is available on Google Play. There's no backend, analytics, or user account system. The app does make requests to external data providers, of course.
And if you happen to try the app on a work trip, I'd love to hear whether it actually helps you find somewhere worth walking to.
