BetweenSFA Group Meeting Point Recommender

Problem Statement

Meeting a friend in San Francisco usually starts the same way: someone asks “where should we go?” and a small, informal negotiation begins. Maps are good at getting one person to a known destination, but they don't help a group decide what that destination should be. Someone suggests a familiar neighborhood, everyone estimates how inconvenient it'll be for them, and the most agreeable person ends up traveling farther than everyone else.

BetweenSF is meant to make that decision easier. Each person shares where they're starting, how they're getting around, and what kind of place they want. The app recommends a neighborhood and a short list of venues that are reasonably fair for the whole group.

Product Model

Shared Flow

The product works without accounts, profiles, or any setup. One person creates a plan with their location, group size, venue preference, and travel mode. The app generates a link they can send to everyone else. Each participant opens that link, adds their own starting point and optionally their name, and once everyone has joined, the shared page updates with recommendations.

The link functions as both the invitation and the product itself. All participants see the same options on the same page and can open personalized directions from their own starting point to any suggested venue.

Fairness Scoring

The initial ranking algorithm treated fairness too literally. It optimized for the smallest variance in travel times across participants, which sometimes recommended a location that was significantly farther for the entire group compared to a slightly less equitable but much closer option.

The scoring was revised to balance equality with total travel burden:

score = 3 × travel-time difference + longest trip

This still favors balanced journeys, but prevents a perfectly equal 30-minute trip from ranking above a slightly uneven 10-minute trip. When participants start near each other, the algorithm shifts to a distance-first discovery mode so nearby venues surface first. Ratings and review counts are only used as tiebreakers after travel convenience has been accounted for.

Location Engine

A geographic midpoint is not always a viable meeting point. In the Bay Area, midpoints frequently land in water, on bridges, or in areas with no relevant businesses. The engine addresses this by starting near the geographic center of all participants, testing candidate areas using real travel-time data rather than straight-line distance, and expanding outward when points are unreachable or impractical. It then queries for matching venues, calculates each participant's travel time, filters out impractical options, and ranks what remains.

For driving plans, the engine also identifies nearby parking garages and estimates the walk distance from each garage to the top-recommended venue.

Interface Design

The interface is designed to feel specific to San Francisco without relying on a literal map. The background is a canvas-rendered, impressionist (Monet at De Young-inspired!) interpretation of the Golden Gate Bridge with a palette that shifts based on local time: pastels during the day, warmer reflections between 6–8pm, and a star-lit, illuminated bridge at night. Each participant is assigned a color that carries through their location card and travel-time display.

Iteration and Edge Cases

The most useful product decisions emerged from testing uncomfortable edge cases:

• Two participants in the same neighborhood were recommended a venue far away because ratings were weighted above proximity.
• A midpoint between San Francisco and Santa Clara resolved to a location near the Bay with no accessible venues.
• A travel-time difference of one minute was meaningful to the ranking algorithm but irrelevant in conversation.
• Saved plans retained old venue rankings after the scoring algorithm was updated, because results had been cached rather than recomputed.

Each case highlighted a gap between technically correct output and a recommendation that felt reasonable to a person using the product.

Summary

The core challenge was not computing a midpoint but defining what a useful midpoint should mean in practice. A good recommendation needs to account for fairness, convenience, quality, geography, travel mode, and user expectations simultaneously. The algorithm is one part of that—the invitation flow, the copy, the visual hierarchy, and the user's ability to understand why a place was suggested are equally important. BetweenSF is an exercise in making a multi-factor decision feel straightforward.