Quick update since both comments touched on this, shipped the budget filter this week, so worth closing the loop.
On the price level data: the field was always there in the Google Places response, the app just wasn't surfacing it. We now map it on the proxy side, 1–3 become $ / $$ / $$$ directly, and we clamp Google's 4 to 3. The distinction between $$$ and $$$$ isn't meaningful when you're trying to find somewhere four people can agree on. 0 and absent both map to undefined and fall through to "Any." No extra API call, filtering is purely client-side on the already-loaded results.
UX is three chips below the category picker: Any · $ · $$ · $$$. Tap to filter, tap again to clear, resets on category switch. It only shows for Coffee & Casual, Restaurants, and Bars & Nightlife, not for Parks or Museums where price_level is sparsely populated and semantically odd. The honest caveat is that coverage is Google's, not ours. In Paris or London the filter works well; in a smaller city you might filter yourself down to three results. The "Any" default always shows everything, so it degrades cleanly.
Good question on the dead zone case. Right now the system presents the raw reachability overlap rather than penalising anyone's zone explicitly. If someone is in a transit dead zone, their isochrone simply ends up smaller, which naturally constrains the overlap area. The Fairness Score then measures how equitably the resulting venues sit within that overlap — so a venue that’s at the edge of the smaller zone gets scored lower than one closer to the true intersection. It’s implicit rather than explicit penalization, which feels more honest than artificially adjusting one person’s weight.
On ratings — yes, already in. Google Places rating is factored into the venue ranking inside the overlap zone, so the output isn’t just the fairest spot geographically but the best-reviewed option within the fair zone. The two signals are combined rather than sequential. The gap I’m still working on is price level — Google Places has a price tier field but it’s inconsistently populated, which makes it not very reliable as a filter right now.
Hey koher, thanks for your input!
The budget filter is an interesting one, in dense urban areas with lots of venue options it would add real value, since the fairness zone often surfaces 20–30 results and price is a natural next filter. Less relevant in smaller cities where the overlap zone might only return a handful of spots regardless.
The core user is urban, so it fits the direction. Thanks for the suggestion, will add this to the list!
On the price level data: the field was always there in the Google Places response, the app just wasn't surfacing it. We now map it on the proxy side, 1–3 become $ / $$ / $$$ directly, and we clamp Google's 4 to 3. The distinction between $$$ and $$$$ isn't meaningful when you're trying to find somewhere four people can agree on. 0 and absent both map to undefined and fall through to "Any." No extra API call, filtering is purely client-side on the already-loaded results.
UX is three chips below the category picker: Any · $ · $$ · $$$. Tap to filter, tap again to clear, resets on category switch. It only shows for Coffee & Casual, Restaurants, and Bars & Nightlife, not for Parks or Museums where price_level is sparsely populated and semantically odd. The honest caveat is that coverage is Google's, not ours. In Paris or London the filter works well; in a smaller city you might filter yourself down to three results. The "Any" default always shows everything, so it degrades cleanly.
I'll let you give a try! -> hugpoint.io
reply