The product question
For a group choosing where to meet, a geometric midpoint does not answer whether the trip is reasonable for everyone. I explored ranking real venues with a penalty for long and uneven commutes.
What I built
Users add locations; the prototype searches for nearby venue candidates and ranks them with a weighted commute score. A simulation fallback allows the interaction to remain demonstrable when the Places service is unavailable.
The important limitation
Travel times are simulated using distance, an assumed urban speed, and a random multiplier. They are not live routes, traffic estimates, or validated commute predictions.
The original score combines maximum commute and variance. A production score should normalize those quantities before weighting them because time and variance use different units. The weights also need sensitivity testing and user feedback.
How I would improve the decision
Evaluate candidate coverage beyond a centroid search radius, especially around water, transit barriers, and uneven travel modes. Use real route estimates for shortlisted candidates and explain who travels farther.
The next useful comparison is group acceptance and time to agreement against simpler baselines. This prototype does not establish a measured improvement in either metric.
Prototype outcomes
What this prototype demonstrates
- A group venue-ranking interaction with an explicit fairness objective.
- A simulated travel model that makes ranking tradeoffs explorable.
- Clear next steps for route accuracy, score normalization, and candidate coverage.
Technical context
- React & Vite
- Google Places API
- Custom fairness scoring
Up next
Rescue Radar ↗Let’s talk about the product decisions behind the work.
Get in touch ↗