SideQuest

Turn doomscrolling into hangouts. Less screen time, more face time.

Comment

Inspiration

Friends already tell each other where they want to go. We just do it through Reels.

A ramen spot. A rooftop bar. A hiking trail. Someone sends it to the group chat with "we HAVE to go here," everyone agrees... and then nothing happens.

The desire to spend time together is already there. What gets in the way is everything that comes next: figuring out who's interested, finding a time everyone's free, choosing where to go, and actually making the plan.

We built SideQuest to bridge that gap. We keep the fun part—sharing things you're excited about—and let AI handle the coordination. The goal is simple: turn "we should go here" into "we're going."

SideQuest isn't about replacing human connection with AI. It's about using AI to remove the friction that prevents it.

What it does

SideQuest is an iOS app that turns Instagram Reels into real plans with friends.

Share a Reel to SideQuest and Meta Muse Spark 1.3 extracts the place, category, and neighborhood. If the caption doesn't contain enough information, Muse Voice Transcribe can use the Reel's audio instead.

As friends save places, Muse Spark looks for overlaps in their interests. When it finds one, an AI planner checks everyone's Google Calendar for a shared free window, searches for real places, and creates an itinerary.

When a plan is ready, friends receive a live invite. The Plan Detail screen shows an animated itinerary, a map, and our "Why this plan" interest graph, which connects each stop to the friends whose saved Reels inspired it. Places multiple friends wanted are highlighted as shared interests.

Tap Yes, and SideQuest writes the event directly to Google Calendar.

From one Reel to a real hangout.

How we built it

We split development into two parallel tracks: one of us built the iOS experience, while the other built the backend, AI pipeline, and MCP server.

Contract-first development

Before building features, we defined a shared API contract covering our endpoints, request and response types, and realistic mock data.

That let us work independently without blocking each other. The frontend was built entirely against mocks while the backend implemented the same contract. Once both sides were ready, we connected them in a single integration pass.

iOS app

The app is built with Expo, React Native, and TypeScript.

We built a native iOS share extension so users can send a Reel directly from Instagram to SideQuest. React Native Reanimated powers the itinerary animations, React Native Maps renders each plan and its route, and the "Why this plan" graph uses d3-force for its layout and react-native-svg for rendering—without a WebView.

Supabase Realtime pushes newly generated plans directly to invited friends, with polling as a fallback.

AI pipeline

We use Meta's models through the Meta Model API.

Muse Spark 1.3 powers place extraction, overlap detection, and agentic itinerary planning. Muse Voice Transcribe provides a fallback when a Reel caption doesn't contain enough information to identify the location.

The planner doesn't just generate text. Muse Spark can take actions through tool calls, allowing it to gather the real-world context it needs before constructing a plan.

MCP

We built a separate FastMCP server exposing three narrowly scoped tools:

  • calendar_freebusy — finds shared availability across friends
  • places_search — searches Google Places for real locations
  • calendar_write — creates the accepted event in Google Calendar

The MCP server runs as its own Railway service on a private network with no public URL. Google Calendar and Google Places are accessed through these specific tools rather than giving the model unrestricted access to external services.

Our backend is built with Python and FastAPI, while Supabase/Postgres stores application data and powers Realtime.

Building with AI

AI wasn't only part of the product—we also used it heavily in our development workflow.

We ran multiple Claude Code agents in parallel using separate Git worktrees and branches. Agents were given specific areas of ownership and passed written handoff notes between sessions.

Claude Cowork helped us plan development sessions and establish the API contract and mock data that allowed frontend and backend development to happen simultaneously. We also used Supabase MCP so agents could inspect the actual database schema before implementing features against it.

From Telegram to iOS

SideQuest actually started as a Telegram bot.

The Telegram version let us validate the complete planning flow before investing in the native experience. Once that worked end to end, we kept the same core backend logic and added a REST layer for the iOS app.

Moving native gave us the experience we originally wanted: sharing directly from Instagram, live plan notifications, animated itineraries, maps, and a visual explanation of why a group received a particular plan.

Challenges we ran into

Working around platform restrictions

Our original vision was even more automatic: import friends' saved Reels and understand the places being shared inside their group chats.

Platform restrictions changed that approach. Instead, we designed SideQuest around an iOS share extension. Rather than asking users to change how they discover places, SideQuest fits into what they already do: scroll, find something interesting, and tap Share.

Making the share extension reliable

iOS share extensions run separately from the main app under tighter constraints, so we intentionally kept ours lightweight. It captures the shared URL and hands control back to SideQuest, where the ingestion pipeline can run normally.

We also built a paste-a-link fallback so the core experience still works if sharing fails.

Reels don't always tell you where they are

A Reel might show an amazing restaurant without ever naming it clearly in the caption.

Our first layer uses Muse Spark 1.3 to extract structured location information. When the caption is too thin, Muse Voice Transcribe provides another signal from the video's audio. If there still isn't enough information, SideQuest can ask the user for a short hint rather than confidently guessing the wrong place.

Giving an AI real capabilities safely

Our planner needs more than a prompt. It needs access to calendars and real places.

Instead of exposing those services broadly, we created a small MCP surface with only the operations the planner needs. The MCP service itself lives on Railway's private network, and the model interacts with outside services through those narrowly scoped tools.

This let us make the AI genuinely useful without giving it unrestricted access.

Building frontend and backend simultaneously

Our initial assumptions about the database didn't perfectly match the live schema. For example, itinerary information was stored differently than we originally expected.

Rather than building more code around incorrect assumptions, we updated our API contract to match the actual implementation and treated that contract as the boundary between frontend and backend.

It reinforced one of the biggest lessons from the weekend: verify the real system, then build against the contract—not against assumptions.

Real-time systems still need fallbacks

We wanted new plans to feel immediate, so Supabase Realtime pushes them to the app as soon as they're created.

But we didn't want the entire demo—or the product—to depend on one real-time event arriving perfectly. We added polling as a fallback and built recovery paths around the critical demo flow.

What we learned

AI is most useful when it removes friction

The most important thing we learned wasn't about a particular model or framework.

AI didn't need to become another person in the group chat. It was more valuable handling the work nobody in the group wanted to do: interpreting everyone's interests, comparing them, checking schedules, looking up places, and assembling a plan.

The people still decide where they want to go and whether they want to go. AI just helps them get there.

Grounding makes recommendations feel personal

Generating an itinerary wasn't enough. We wanted users to understand why SideQuest chose it.

That led to the "Why this plan" graph. Every stop connects back to the friends and saved Reels that inspired it.

Instead of saying, "AI thinks you should go here," SideQuest can effectively say, "You wanted this. Maya wanted this. That's why it's part of your Saturday."

Tool-calling turns generation into action

Muse Spark isn't just producing an itinerary from information in a prompt. It can call our MCP tools to retrieve availability and places, reason over those results, and construct a plan grounded in real information.

Then, when the user accepts, another tool call turns that output into an actual calendar event.

That changed how we thought about AI applications: the interesting part isn't just what a model can say, but what it can coordinate.

Contract-first development let two people move like a larger team

Defining the API before building it meant neither of us had to wait for the other.

Mocks gave the frontend something realistic to build against. The contract gave the backend an exact target. That separation became especially valuable when AI coding agents were also working in parallel.

Orchestrating coding agents is its own engineering problem

Running several AI coding agents simultaneously can create more problems than it solves without clear boundaries.

We learned to give agents explicit file ownership, freeze shared files when necessary, isolate work in separate branches and worktrees, and require written handoffs.

The biggest productivity gains didn't come from simply adding more agents. They came from coordinating them well.

What's next

We want SideQuest to become a shared layer between discovering something online and actually experiencing it together.

Next, we want to support larger group plans with time and activity voting, let users choose whether a plan is for specific friends, their broader friend group, or people with similar interests, and create shared post-hangout memories.

We also want to build Vacation Wrapped: a visual recap of the places you and your friends actually experienced together.

Ultimately, SideQuest is built around a simple idea: social media already shows us what our friends want to do. AI can help us stop leaving those plans in the group chat.

Less screen time More face time.

Built With

Share this project:

Updates