Side by Side

Inspiration

Meeting someone new can be surprisingly difficult when you are standing right next to them. You might share an interest, a class, or a goal, but neither person knows whether a conversation would be welcome—or how to start one.

We built SidebySide to reduce that uncertainty and encourage people to get off the app and talk in person. Instead of asking users to swipe through strangers, SidebySide helps them describe what they care about, discover people nearby, and decide together whether to connect. AI can offer a reason to talk and a useful first question, but the people make the decision. Our goal is to get YOU and your interactions off the app; real connections are made in real life.

We also wanted to explore what social discovery could look like beyond a phone. Our Companion Charm and Meta Quest 3 hardware investigate how a physical marker and an optional AR experience might help someone recognize an already approved connection in the real world.

How We Built It

SidebySide includes a website and a native iPhone app built with Expo and React Native. The website supports location-based discovery, while the native app adds foreground Bluetooth discovery. A FastAPI backend coordinates matching and application logic. Supabase provides authentication, PostgreSQL storage, access controls, and PostGIS queries for nearby discovery. We also built a hardware around an M5Stack Core2 Companion Charm. It displays a stable AprilTag as a visual anchor and can signal temporary nearby presence over Bluetooth when sharing is enabled. A Meta Quest 3 passthrough prototype explores how a consent-controlled AR introduction might work. The public marker or Bluetooth signal alone does not authorize revealing a profile.

During onboarding, users answer questions about their interests, experiences, conversation goals, and the kinds of interactions they enjoy. Meta’s Muse API helps draft questions and turns answers into structured, editable profile information. Users review and approve what becomes part of their profile and what may be used for matching.

Our matcher evaluates a specific, directional conversation request, rather than asking whether two profiles look generally alike. For example, “I want to learn robotics from someone who has built a robot” is different from “I want to find another beginner to build a robot with.” The backend builds that request from an immutable profile snapshot and the person’s approved onboarding answers. It checks that the answers belong to the account, that the relevant facts were approved for matching, and that the conversation request is still current.

The inference pipeline has three distinct jobs. First, Qwen3-Reranker-4B compares the requester’s goal and approved facts with the candidate’s approved facts and stated openness to talk. It produces a relevance signal from its final yes/no token scores. Second, when the request requires firsthand experience, DeBERTa performs a textual entailment check: do the approved fact and its original answer both support the specific claim? Reading the original answer matters because a short excerpt could omit a qualification such as “I haven’t done this yet.” This checks textual support, not whether someone is truly an expert. Third, MiniLM converts explicit conversation-style preferences into normalized embeddings so we can compare preferences such as hands-on collaboration versus a technical debate. A format mismatch can reduce a high relevance result or prevent a recommendation.

The backend combines the relevance and format signals, then applies a calibration and decision policy selected through experiments with synthetic, fictional pairs on UCF’s Newton GPU cluster. Some real, opt-in profiles from hackathon participants were also included in the data used to train the matching system. The resulting score is not a measured probability that two people will become friends. Missing or unconfirmed evidence produces insufficient_evidence rather than a misleading low score. If the model assets or worker are unavailable, the result is unavailable. Only a supported recommend result can become a discovery suggestion, and consent, availability, blocks, and mutual acceptance remain separate application checks.

A queued worker runs inference when eligible nearby pairs need a current result. Profile changes and other relevant state changes invalidate old results so a suggestion is tied to the information people actually approved at that time. Muse is a separate generative layer: it helps draft onboarding information and proposes conversation starters or activity ideas, while the matching models and backend policy decide whether there is enough support to show the suggestion.

Challenges and What We Learned

Our central AI challenge was understanding the difference between similarity and a useful recommendation. Two profiles may discuss the same subject, but that does not prove one person has the experience the other requested. A high relevance score also does not tell us whether both people want the same type of conversation. We learned to keep relevance, supporting evidence, and mutual consent as separate decisions.

We used synthetic profiles to create controlled examples and find failure cases, and included some real, opt-in profiles from hackathon participants in the data used to train the matching system. Real answers brought more varied goals and ways of describing interests than our fictional examples. They also made it important to track where training examples came from and to distinguish training results from real-world outcomes. Including participant profiles does not, by itself, show that a recommendation will lead to a welcome or worthwhile conversation. That requires feedback from the people who actually meet.

Engineering the full experience was another challenge. A website, two phones, Bluetooth, location services, a GPU worker, a physical charm, and a headset each have different permissions and failure modes. We worked through issues with phone-to-server networking, location freshness, native Bluetooth configuration, device pairing, model availability, and authentication emails. We learned that the app needs to explain states such as “insufficient evidence” or “matching unavailable” rather than disguise them as a low compatibility score.

Privacy shaped the project from the start. People approve profile facts, opt in to discovery, and choose whether to accept a connection. Even in the hardware concept, detecting an AprilTag is not permission to show personal information.

What’s Next

We used synthetic examples and some opt-in hackathon participant profiles to develop the matching system. Next, we want to evaluate it against real conversations: did both people choose to connect, did they meet, and would they talk again? Those outcomes will tell us more than a relevance score alone. With participants’ permission, we could use that feedback to improve future ranking while keeping a missed message or a busy day from being treated as a negative review.

We also want to strengthen the experience across devices. That means completing two-phone Bluetooth tests, improving matching speed and reliability, and making the transition from a nearby suggestion to a mutually accepted connection feel seamless on both the website and native app.

Our longer-term goal is a lighter AR glasses experience. The Companion Charm could provide a visual anchor, while Comet, our friendly AI character, offers an optional conversation starter or activity idea after both people have agreed to connect. The technology should help people begin a conversation, then step out of the way so they can build the connection themselves.