Gathr
A private-alpha local planning product with discovery, joining, confirmation, group chat, reliability, safety, privacy, launch boundaries, and reviewer proof paths.
What it is
Gathr is about getting people from intent to actually showing up. The product loop is deliberately concrete: choose a neighborhood hub, find an activity, join a small group, chat, confirm, check in, and keep a lightweight memory afterward.
The interesting product work is trust. Reliability, cancellation penalties, safety reports, blocked users, and privacy export/delete are treated as part of the core experience, not as future admin polish.
The loop it has to make believable
- 01
Built the activity lifecycle from discovery to attendance, including feed sections, join/leave, confirmation, check-in, completion, feedback, and Drops.
- 02
Modeled reliability as backend state with human-readable blocking reasons rather than simple UI messaging.
How it’s built
The backend owns the product contracts that matter: activity state, join and confirmation rules, chat delivery, reliability movement, safety reports, blocked users, privacy export/delete, launch flags, and reviewer-mode fallbacks.
The repo also contains recommender substrate: event tracking, feature-store concepts, model-serving hooks, promotion gates, semantic search, and graph ideas. The honest alpha story is still heuristic/fallback-first ranking, not a trained production recommendation model.
Architecture
- Product loop
- Hub selection, feed browse, activity join, group chat, confirmation, check-in, post-meet Drop
- State
- Backend-owned activity lifecycle, reliability movement, blocked-action reasons, safety reports, privacy export/delete
- Realtime
- Activity-scoped chat with fallback behavior, typing, presence, rate limits, idempotent client message IDs
- Launch boundary
- Private beta channel, one coded hub, Expo push provider, account deletion, non-core surfaces frozen off
- Reviewer surfaces
- Static web demo, local backend/mobile verification guide, launch manifest, release contracts, and runbooks
What has to hold up
- Implemented realtime activity chat with WebSocket delivery paths, typing/presence, rate limiting, and blocked-user filtering.
- Kept the alpha honest with a static sample-data web preview, demo-mode backend deploy, launch flags, release contracts, and a clear boundary between heuristic ranking and future model-backed ranking.
How I would present it
I would start with the static web demo to show the loop quickly, then go into the backend: activity state transitions, reliability score updates, chat delivery, privacy endpoints, and launch-mode configuration.
The strongest interview angle is product logic under real constraints: attendance, trust, safety, privacy, realtime communication, and staged rollout.
Proof
VerifyRepository, checks, stack, status
- 01
Open the GitHub repo README, then read START_HERE for the current doc map.
- 02
Open the static web demo notes to understand the reviewer-facing product loop without installing the mobile app.
- 03
Read the architecture section below for activity state, access, chat, reliability, safety, privacy, and launch boundaries.
- 04
Inspect LaunchManifest, LOCAL_VERIFY, backend/mobile verification docs, and the release contracts before making production claims.
- Role
- Backend architecture, product logic, trust/safety, mobile integration, reviewer proof path
- Scope
- Private-alpha local social planning product with backend, mobile app, and static web demo
- Proof
- README, START_HERE, LaunchManifest, LOCAL_VERIFY, static web demo, backend/mobile verification docs
- Stack
- Java, Spring Boot, PostgreSQL, Redis, Flyway, WebSocket/STOMP, Expo
- Loop
- Discovery to attendance
- Access
- Phone OTP
- Review
- Static web demo
- Channel
- Private beta