Huddle

Agentic, real-time group planning: a privacy-preserving LLM coordinator, grounded in scraped & curated Bright Data venues, emits schema-validated plans; votes are a database-enforced secret ballot.

Comment

Inspiration

Do your plans never make it out of the group chat? Do you try to use AI to plan your events but for some reason they never work? Did your friend forget to tell you that they're vegan, resulting in dinner cancellation? Then, a whole day goes by while that day trip never happens. Worry not! For these scenarios have happened to the best of us! Luckily, we thought of 'Huddle', the solution to uncooperative group/date-planning!

What it does

Huddle turns “where should we go?” into one concise and followable plan. Everyone joins with an account, which lets the host invite other registered users. Each person privately connects their calendar, enters their preferences, budget and dietary needs, and nobody else can see them. When the host starts planning, our planner builds every itinerary that fits the whole group, and a Claude agent picks the best few, each with a map and directions. The group votes in a secret ballot, with a tiebreaker if needed, and the winning option comes with a shareable result link and can be added straight to everyone's Google Calendar.

How we built it

  • Real-time backend. A SpacetimeDB module on Maincloud holds the shared state/backend. Each person's private needs sit behind per-identity views, so other clients cannot read them at all.
  • The agent. A human-in-the-loop Claude agent reads each person’s private preferences. Our planner then builds every itinerary that fits everyone’s hours, travel and budgets, then passing it forwards to the agent; the agent then picks the best few with each person’s preferences, and code validates its answers. Humans make every final call as each person confirms their needs, the host starts planning, and the group decides by secret vote.
  • Data. Bright Data scraped 5,900+ places across Berkeley, Oakland and San Francisco (Google Maps listings and venue sites). We curated 200 venues with real photos, hours and ratings, plus 950 menu items, and the coordinator can only choose from them. Google Places API was used to build this catalog.
  • Frontend. React 19, React Router and Vite on Vercel, with embedded Google Maps. Then, the UI is a hand-drawn doodle style, inspired by skribbl.io: crayon-hatched skies, line boil animation, and flat colors; point is, we were really trying to go for that friendly and social feel.

Every plan is checked before anyone sees it. Each stop in a plan has a per-person cost, and some members have a private spending cap. A plan is valid only if the total per-person cost of all its stops is no more than every member's spending cap. The ballot is revealed only once every member has voted, meaning the number of votes equals the number of members. That rule lives in the database view, not in the UI.

Challenges we ran into

  • Making LLM output safe to show. Plans that name an unknown venue or go over someone's cap are rejected through validation checks, and plans go stale if anyone changes their needs.
  • Switching APIs We wanted to use Yelp, but getting a Yelp API wasn't possible, and scraping Yelp with Bright Data returned no results. So we had to use Google Maps reviews
  • Logic error on time available We spent hours trying to find out why plans came out to one stop when all users put two and above stops, turns out when given not enough time, it's impossible to make more than n stops. As a result, they do not display. We ended up putting a warning for this edge case.
  • Platform quirks and teamwork. SpacetimeDB migration rules, ID collisions, and three people merging UI changes in one day, including features that disappeared in merges and had to be rebuilt.

What we learned

  • Large amounts of data != quality data
  • Python is slow but flexible
  • Always attempt to host on existing backend services
  • The biggest problems are usually logical, not syntax
  • Managing scope creep is just as important as making the MVP

What's next for Huddle given more time

  • Due to a limited amount of time, we are limited to gathering data from the bigger Bay Area cities. Given more time and resources, we can turn this into a real product that scrapes data from the entire Bay Area, and then the entire state of California, then the entire West Coast, and onwards!
  • Expanding outside of restaurants, parks, and other basic areas. And allow for reservations to be booked with agents
  • Moving away from the Cloudflare tunnels and having the machine subscribed to SpacetimeDB instead of being called, meaning no more tunnel/public URL
  • context.dev can be implemented as a supplemental web scraper tool, utilizing both Bright Data and context.dev will provide double coverage with the former acting more like a hammer (mass scrape), and the latter acting like a scalpel (on-demand precise scrape), making sure websites are scraped to the maximum level. We actually built and tested a context.dev fallback on a separate unmerged branch

Built With

Share this project:

Updates

Submission history