Try to find every cafe in a mid-sized city rated 4.8 stars or higher with at least 1,000 reviews, using Google Maps directly, and you'll hit a wall fast. Search results cap out at roughly 60 places per query, and there's no way to filter by strict rating-and-review-count combinations in the native app. If there are more than 60 cafes that could plausibly match, you simply never see most of them. GeoGem exists to get past that cap.
The problem
The 60-result cap isn't a bug, it's just how the standard search API is designed — it returns the "best" matches for a broad query, not an exhaustive list. That's fine for casual browsing, but it breaks down the moment you need something closer to a real filter: "every place with these exact characteristics in this exact area," rather than "some good options nearby."
How it's built
GeoGem is a Next.js 14 app where you draw a rectangle over the area you care about on an interactive map. Instead of sending one search request for the whole rectangle, it splits that area into a grid of much smaller micro-zones and fires a parallel Google Places API (New) request for each one. Since each micro-zone has far fewer than 60 places in it, nothing gets truncated — the aggregate result across all zones ends up being the full, exhaustive set instead of a capped sample.
Once the results are in, a filter sidebar with rating and review-count sliders lets you narrow thousands of aggregated businesses down to exactly the combination you're after, with matches shown as color-coded (green/yellow/red) markers on the map.
Results are cached in a Supabase Postgres database using PostGIS for spatial queries, so re-scanning an area you've already covered doesn't mean re-paying for the same API calls. The stack is React and TypeScript with Tailwind CSS on the frontend, server-side API routes handling the Places API calls, deployed on Vercel.
Why grid-scanning works
The core trick is simple once you see it: an API limit on results-per-query isn't the same as a limit on results-per-area, as long as you're willing to issue more queries over smaller areas. The engineering problem shifts from "how do I get more results per call" (you can't, it's a fixed cap) to "how do I split the area finely enough that no single call ever needs more than the cap allows" — which is a solvable problem, and one that scales with however fine-grained you're willing to make the grid.
Try it
The code is on GitHub. If you've ever given up on a Google Maps search because the results felt incomplete, this is what "actually exhaustive" looks like instead.