How I Mapped 1,294 Vet Clinics in Istanbul Using Mapbox and Next.js

Istanbul has 1,294 vet clinics. I mapped all of them.

When you have a pet emergency at 2am in Istanbul — a city of 15 million people — you need to find an open vet clinic fast. The problem is that no reliable directory existed. Google Maps returns inconsistent results. Clinic websites are often outdated. You call a number and it rings out. This is the problem I set out to solve with En Yakın Veteriner — and the solution required solving some genuinely interesting technical challenges. Here's how it was built.

The technical problem: real-time location and open/closed status at scale

The core challenge was twofold: getting accurate data on 1,294 clinics across 20+ Istanbul districts, and providing real-time open/closed status so users wouldn't drive across the city to a closed clinic. For the data, I sourced clinic information from multiple public registries and municipal databases, cross-referencing and deduplicating to build a verified dataset. Each clinic record includes name, address, phone number, GPS coordinates, opening hours, and 24/7 status.

The open/closed status is calculated server-side based on the clinic's stored opening hours and the current time in Istanbul (UTC+3). This avoids the user having to interpret raw opening hours themselves — the app tells them definitively: open now, or closed. For the 242 clinics confirmed as 24/7 operations, this is always "open." For the rest, the status changes dynamically throughout the day.

The frontend is built in Next.js with TypeScript. Map rendering uses Mapbox GL JS, chosen over Google Maps for its performance with large numbers of map markers and its more flexible styling options. The clinic data is served from a Next.js API route that returns the full dataset filtered by bounding box, preventing the overhead of loading all 1,294 markers on initial page load.

GPS proximity sorting and the one-tap call UX decision

The key UX decision was making GPS the primary navigation metaphor. When a user opens the app, the first prompt is for location access. If granted, the clinic list is immediately sorted by distance from the user's current location — nearest first, with distance displayed in kilometres. If the user is in Kadıköy, they see Kadıköy clinics first. If they're in Şişli, Şişli clinics appear at the top. This sounds obvious, but it required careful handling of the navigator.geolocation API, which has different permission and timeout behaviours across iOS Safari, Chrome Android, and desktop browsers.

The fallback when location is denied is a district selector — users can choose their district from a dropdown and see clinics in that area sorted by name. This is less ideal than GPS sorting but ensures the app is fully functional even without location permission.

The one-tap call feature was the most debated UX decision. On mobile, each clinic card has a prominent phone button that opens a native phone call without copying the number to the clipboard. This was specifically designed for emergency situations where the user is stressed and time-poor. A user in an emergency should never need to copy a number, open their phone app, paste it, and dial. One tap.

What businesses can learn from building location-based apps

Location-based applications have three failure modes that are easy to overlook until they affect real users. First, data freshness: a clinic that's moved or closed represents a broken trust moment for a user who drove there. Build a feedback mechanism from day one and plan for regular data verification. Second, fallback UX when location is denied: too many location apps show an empty screen when the user denies location permission. Design the no-permission state explicitly — it's not an edge case, it's a significant portion of users. Third, accessibility for maps: screen reader users can't interact with a Mapbox map in the conventional sense. The clinic list view needs to be the primary accessible interface, with the map as a secondary visual aid.

Key takeaways for businesses

• GPS proximity sorting dramatically improves the utility of any directory or finder app for mobile users — implement it as the default sort, not an option.
• Plan for the location-denied state explicitly. Between 30–40% of mobile users deny location permission on first prompt.
• Real-time computed data (open/closed status from stored hours) is significantly more reliable than asking businesses to manually update their status.

Frequently Asked Questions

How do I build a geolocation app with Next.js?

Use the navigator.geolocation.getCurrentPosition API in a client component to get user coordinates, then pass those coordinates to your data layer to sort or filter results by proximity. Handle the three states explicitly: permission granted, permission denied, and permission pending. Serve map tiles via Mapbox GL JS or Leaflet for the visual map layer.

What is the best map library for web applications in 2026?

Mapbox GL JS is the most capable option for custom-styled maps with large numbers of markers and interactive layers. Leaflet is a lighter alternative for simpler use cases. Google Maps JavaScript API is the most familiar but carries per-request costs that scale significantly for high-traffic applications. For Next.js projects, react-map-gl (a Mapbox wrapper) integrates cleanly with React's component model.

How do I get real-time business open/closed status for a directory?

The most reliable approach is to store structured opening hours per business (e.g., Monday: 09:00–18:00) and compute the open/closed status server-side from the current time in the business's timezone. This avoids dependency on businesses manually updating their status and scales to thousands of listings without additional infrastructure.

Building a location-based product?

I've built production geolocation apps with Mapbox, Google Maps API, and the browser Geolocation API. If you're planning a finder, directory, or map-based product, let's talk through the architecture.