Hither

Inspiration

Group travel often fails at the same point: one person decides where to meet, while everyone else has to infer the destination, watch a chat thread, and estimate whether they are falling behind. Hither was built to make group coordination spatial rather than conversational: a leader sets the active meeting point, and members can immediately see where to go and how far away they are.

What it does

Hither is a mobile group rendezvous app built around a Leader–Follower model. A leader creates a group and sets an active meeting point; members join with a short group code and view the destination and relative distance on a shared map.

The product also supports itinerary meet times, configurable straggler alerts, onboarding paths for leaders, members, and browsers, map themes, KML import for planned routes, feedback reporting, and iOS Live Activity support for at-a-glance meeting status.

How we built it

We built Hither as a React Native application using Expo, with platform-specific abstractions where native behavior differs. The map layer uses Apple MapKit on iOS and is designed to use Google Maps on Android, while location and permission handling are isolated behind service interfaces.

Supabase provides authentication, PostgreSQL data storage, row-level access control, and backend workflows. Core persistent entities include users, groups, memberships, meeting points, itinerary items, and profile preferences; transient location updates are handled separately from durable group data.

For the user experience, we implemented role-specific onboarding, configurable visual themes, haptic feedback, a map-based group interface, destination meet-time controls, distance-based straggler detection, KML parsing and import, in-app activity logging, and feedback reporting with screenshots.

Challenges we ran into

• Cross-platform maps: iOS and Android map providers, location permissions, and background-location behavior have different APIs and runtime constraints, so platform-specific code needed to remain behind a shared interface.
• Location accuracy versus battery use: the MVP needed location updates frequent enough for group coordination without treating navigation-grade tracking as a requirement; the design therefore targets bounded, periodic updates rather than continuous turn-by-turn routing.
• Real-time group state: the system must distinguish durable state, such as a meeting point or group membership, from rapidly changing location data that should not create unnecessary database writes.
• Native iOS integration: Live Activities require native ActivityKit and APNs integration, which cannot be fully validated in Expo Go and requires a development build.
• Safe group access: group codes simplify joining, but authorization still has to enforce leader and member roles through backend policies rather than relying on client-side UI state.

Accomplishments that we're proud of

• Defined a focused MVP around the complete rendezvous loop: create a group, join by code, set a meeting point, and show each member’s distance to it.
• Kept the product scope disciplined by excluding features such as AR overlays, AI features, full navigation, and QR-code joining from the initial core flow.
• Built onboarding that adapts to three entry paths—leader, member, and browser—rather than assuming every user begins with the same intent.
• Added operational feedback loops through activity logs, exception reporting, screenshot-based feedback, PostHog analytics, and Sentry error monitoring.
• Implemented automated validation across the product surface, including onboarding, KML import, group features, and schema migrations.

What we learned

We learned that “real-time location” is not a single feature. It combines permission design, platform lifecycle constraints, battery policy, privacy boundaries, data modeling, and UI clarity.

We also learned to separate a product’s coordination primitive from its optional features. Hither’s primitive is the active meeting point; group splitting, route import, alerts, monetization, and richer visual layers are useful only when they reinforce that central workflow.

Finally, we learned that cross-platform development works best when shared product logic is separated from platform capabilities early, especially for maps, location services, native purchases, and iOS-only Live Activities.

What's next for Hither

Next, we plan to complete production-grade real-time updates and push-notification fan-out, expand Android support, and validate the iOS Live Activity workflow in development builds.

We also plan to refine group coordination features already specified in the roadmap: subgroup splitting, route and KML workflows, configurable straggler thresholds, paid Pro entitlements, and native in-app purchase integration.

Built With

• expo.io
• react-native
• supabase
• swift