Show HN: hugpoint.io – Find the fairest meeting spot for a group(hugpoint.io)
hugpoint.io
Show HN: hugpoint.io – Find the fairest meeting spot for a group
https://hugpoint.io/
5 comments
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.
I'll let you give a try! -> hugpoint.io
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
The anchoring point is real and you've framed it well. Most people don't even realize the first suggestion wins 80% of the time, they just go along with it.
The transit data angle is the differentiator here — straight-line midpoints are useless in cities with asymmetric transit coverage. Curious how you're handling cases where one person is in a transit dead zone and others are on a good line. Does the fairness score penalize that person's zone or just present the raw reachability overlap?
Also the budget filter suggestion in comments is interesting — have you thought about layering in venue ratings so the "fairest spot" is also the best-reviewed option in the overlap zone?
The transit data angle is the differentiator here — straight-line midpoints are useless in cities with asymmetric transit coverage. Curious how you're handling cases where one person is in a transit dead zone and others are on a good line. Does the fairness score penalize that person's zone or just present the raw reachability overlap?
Also the budget filter suggestion in comments is interesting — have you thought about layering in venue ratings so the "fairest spot" is also the best-reviewed option in the overlap zone?
Hey matrixgard
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.
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.
Amazing! Love the idea. Do you think it would be a good idea to also maybe include an option to select locations based on group budget?
Just a thought, but apart from that, love it!
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!
Everyone else agrees to avoid friction. Someone ends up with a disproportionate commute. Nobody mentions it.
The tool calculates each person's reachable zone using real transit data (not straight-line distance), finds the intersection, and surfaces Google Places results inside that overlap — ranked by a Fairness Score that measures how equally reachable a venue is for everyone in the group. Technical decisions worth discussing:
Isochrone-based rather than Euclidean midpoint — crow-flies distance is meaningless in a city with asymmetric transit
Per-person travel mode support — one person cycling, another on the Subway, a third driving
Session state serialised to URL hash so any search is shareable without accounts
Built entirely with AI tools as a non-technical founder — happy to talk about that process if useful
No accounts, no paywall, works in the browser.
Would genuinely appreciate feedback on the technical approach and any edge cases you'd throw at it.
hugpoint.io