HomePage
QuestPage
Goals
Share Online!
Track

Inspiration

Every friend group has a “we should hang out” conversation that never becomes a plan. Finding a place is only part of the problem: someone has a different budget, someone gets off work late, and the details disappear in the chat. We built SideQuest to help existing friends spend more time together, with less coordination.

What it does

SideQuest turns a request like “something fun Friday after seven, around $25 each” into a plan the group can agree on. SideQuest, our agent, works through iMessage using Claw Messenger and through the website at getsidequest.tech. Friends can start with one request; interests and refinements are optional.

The app compares up to three sourced outings, shows known times and costs, collects acceptable choices and favorites, and keeps private constraints out of group messages. Google Calendar free/busy and manual availability provide scheduling inputs. When a material constraint changes, the proposal changes version and earlier votes cannot approve the new plan. Agreed plans offer an own-calendar action and an ICS download.

The outing can become a small quest: three cooperative photo challenges and two riddles. The website also includes custom badges, photo and voice-memo memories, and sharing handoffs. Current memories are stored on the device. Instagram/Facebook sharing opens the user's sharing workflow; it does not automatically publish through their APIs.

For judges, /try is a phone-free, clearly labeled simulation with fictional friends. It walks through availability, options, voting, a simulated reservation, quests, badges and memories without sending messages or spending money.

How we built it

We built a TypeScript monorepo with a Next.js/React web app and a persistent background worker sharing one backend.

Meta Muse: Muse Spark interprets requests, extracts reviewable interests, finds common ground using confirmed evidence from at least two friends, and produces structured planning and quest outputs. Zod validates the outputs; application code checks hard constraints and permissions. Muse Voice transcribes WAV recordings into editable drafts, Spark can describe an uploaded interest photo, and Muse Image can illustrate a quest. Those optional media paths passed live provider checks in our integration harness.

SerpApi: Maps, events and search discovery supply actual venue candidates, source URLs and fetched-time evidence. SideQuest can research public pages for missing details. Missing prices or showtimes stay unknown instead of becoming invented facts.

The platform behind SideQuest: Movie-night and local-outing recipes reuse the same runner and tools. Authorized teammates can edit instructions, allowed tools and execution limits in Studio. Each save creates a recipe version; run records retain the version, model/tool steps, timings, token usage and available cost estimates. This makes behavior inspectable and configurable beyond a single prompt.

Tiger Data: Tiger Postgres stores accounts, friendships, scoped conversations, private facts, plan versions, votes, jobs and run records. Transactions, deduplication and conversation ordering keep the web and Messages views tied to the same state. Private facts and recipient data are encrypted, and private routes enforce membership.

Vultr and .TECH: Docker Compose runs the web app and worker on Vultr, behind Caddy HTTPS at getsidequest.tech. GitHub Actions runs checks before deployment and verifies health, with rollback support.

Snowflake Cortex: We implemented an optional conversation recap. A member selects group messages and explicitly consents to sending their text to the Cortex Chat Completions API. The response separates ideas, concerns and questions, and each item must cite an exact quote from a selected message. Private threads are excluded and recaps never cast votes or modify plans. This path passed mocked API/UI checks; live Cortex access remains unverified because of account network restrictions.

Challenges we ran into

The difficult part was keeping a changing conversation consistent across a website, worker and messaging provider. We added version checks, durable jobs and duplicate-event protection so a delayed response or retry could not silently approve stale options.

Venue search often returns incomplete prices and showtimes. We preserved evidence and unknown fields rather than making a polished but unreliable itinerary. Model availability and provider/network restrictions also required bounded retries and clear fallbacks.

Booking is another boundary: a calendar event does not reserve a venue. Our fulfillment layer separates quotes, buyer approval, checkout handoff and reported or confirmed outcomes. Production uses a merchant handoff when an automated driver is unavailable; the public walkthrough labels its reservation as simulated.

Accomplishments that we're proud of

We connected live Muse and SerpApi calls with Tiger persistence in an integration walkthrough: three synthetic friends received sourced options, approved the same version, and completed a shared five-part quest. The deployed app also has a working Claw delivery path; production OTP delivery was received by a tester.

We built a reusable, versioned agent system with actual run traces, and a paper/ink/gold interface that carries through the map, quest scroll, custom badges and memories. The public demo lets someone understand the whole experience without onboarding. Desktop/mobile browser tests cover the major flows alongside backend, account and fulfillment checks.

What we learned

An AI planner becomes useful when its suggestions connect to reliable state and real evidence. The model can propose and explain; code must decide who is allowed to act, whether a constraint is satisfied, and which version people approved. We also learned that consent and fallbacks are product features: friends should be able to participate without connecting a calendar or sharing personal interests.

What's next for SideQuest

Our next step is testing with real friend groups and finishing real-account acceptance checks for calendar and booking flows. We want server-synced memories and completion-based badge history across devices, better next-outing suggestions from feedback people choose to share, and a verified live Snowflake recap. Direct social publishing would require the appropriate account permissions and platform approval.