Settings

Product

Roadmap

Last reviewed 2026-03-27

Lets Eat helps a group pick a place to eat: start a session, set filters, invite people, swipe on venues, then land on a match with ranked picks, host lock-in, maps, and directions — with optional push and in-app alerts.

What's live today

Sessions & identity

  • Create, list, and join sessions backed by Postgres
  • Invite links and deep links (`/join/:code`, `?sessionId=` on filters & vote)
  • Clerk sign-in; host and members tied to Clerk user IDs
  • Host can start the session (moves from draft → voting)

Filters & venues

  • Session filters: cuisine, price, dining style, radius, area search, schedule
  • Map + Google Places search; host refreshes candidate restaurants into the session
  • Vote stack loads real venues from your session’s candidate list

Voting

  • Swipe / pass persisted per person and venue
  • Group voting progress and completion summary (refetch-based)

Matching

  • Consensus-style ranking (max likes, fewer passes, then name) with unanimous / majority / tie badges
  • Match page: leaderboard, host lock-in, OpenStreetMap preview, Google Maps directions links

Social

  • Friends: requests, accept/decline, list
  • Friend groups for quicker invites from filters

Admin

  • Read-only admin views for sessions and usersClerk metadata role `admin`; Admin link in nav when public metadata is set

Notifications

  • Web Push subscriptions and in-app inbox (NotificationBell)
  • Friend session invites with `/join/session` — push + in-app when someone invites you
  • Alert when the host locks a restaurant (decision notifications)

Platform

  • TanStack Start, Cloudflare Workers deploy, Drizzle + Postgres schema
  • Server functions with membership and host checks on mutations
  • Default route loading + error UI (`RoutePendingFallback`, `RouteErrorPage`); reusable `AsyncStatus` for client fetches

Heads up

  • Match: “reserve” and similar booking actions are still placeholders.
  • The `open` (“Gathering”) status exists for future flows; new sessions still start as `draft`.
  • Vote progress and the match page refresh on navigation / refetch — not live WebSockets yet.

Planned next

Matching

  • Optional: alternate consensus rules (e.g. maximize minimum satisfaction)
  • Reserve / booking integrations from the match screen

Sessions

  • Optional: use the `open` status in the flow (e.g. after invites, before voting)
  • Optional: host “reopen” or duplicate session after a decision

Experience & quality

  • Automated tests for critical flows (Vitest is available; tests not written yet)
  • Optional: per-route custom errorComponent / refine AsyncStatus usage
  • Deeper observability (metrics beyond basic logging)
  • Optional: live vote updates (e.g. WebSockets) instead of polling/refetch

Milestones (high level)

  1. 1.M1 — Real sessions: done (create/join/link invite + Clerk + direct friend invites).
  2. 2.M2 — Venues: done (filters + Google + candidates + vote list).
  3. 3.M3 — Vote + match: done (votes, consensus ranking, host lock-in, `/match` + notifications).
  4. 4.M4 — Polish next: automated tests, optional `open` lifecycle, booking integrations, deeper observability.

Detailed status lives in plan/roadmap.md in the repo — keep it in sync when you change this page.