Bruin Plans

Plans die in group chats; clubs too formal for the average hangout. Bruin Plans brings a casual hangout to life --- one chat for time, place. All you need to do is: Find a plan. Join it. Show up.

Comment

Inspiration

As first years, we felt that making connections or creating plans to go out in general to be incredibly difficult. Oftentimes, our plans would never leave the group chat, and clubs were not always the most appropriate place to find someone to simply get dinner or study with. We saw that this issue wasn't necessarily because people didn't want to hang out; rather, a lack of coordination would result in miscommunication, or a person asking about an event that already passed. That's why we wanted to create an app that combined social media, cross-platform messaging, and event planning all into one easy-to-use and accessible app. It would keep track of attendees, time, place, and capacity: all factors that we believe were the main concerns regarding casual event planning. We believe that our app will be an easy and convenient way to meet new people and make life-long connections!

What it does

Our app lists all current events alongside crucial information: time, place, capacity, and list of attendees. Users can either join existing events or create one of their own. Such events are categorized by type of plan, such as grabbing a meal, studying, or even exploring a new place. When searching for events, users can filter out by popularity or by said categories. There are no restrictions on where such event needs to be hosted at, which is perfect for both on-campus and off-campus activities. When creating an event, a group chat is automatically created for each posting. When another person decides to join that group, they are automatically entered into said group chat Furthermore, users can edit their profile, report any events/users, and rate other users based on their experiences.

How I built it

We built the app using React Native and Expo so it could run smoothly on iOS while staying flexible. This also ensured that our idea would come to life through an app, which would increase accessibility. Furthermore, we used Supabase as our entire backend: handling authentication, a PostgreSQL database, realtime messaging, and photo storage under one roof. TypeScript kept the codebase stable as the data models grew more complex. The file-based routing from Expo Router made it easy to keep the navigation clean as we added screens for discovery, event detail, chat, and reporting.

Challenges I ran into

The hardest challenges were the ones that don't show up in a feature list. Getting realtime chat to feel tied to a specific event — not just any other chat that existed in our app — required careful thinking about how conversations and event objects related to each other. Trust and safety also was a crucial part of gaining traction, as building the report flow and row-level security policies early forced us to think seriously about what it means to open create an app by UCLA students for UCLA students. Finally, scoping was a constant discipline since there were a dozen features we could have built; however, we kept asking whether each one actually helped a student lean from indecision to clear certainty.

Accomplishments that I'm proud of

Getting the core loop to actually work end-to-end — discover a plan, join it, chat with attendees, and report if something feels off — was the accomplishment we're most proud of. It may be simple on the surface, but every piece had to connect cleanly: capacity had to update on join, the chat had to be scoped to that specific event, and the report had to carry enough context to be useful for moderation. We're also proud of building trust and safety in from day one rather than bolting it on later, and of the discipline it took to keep the product focused on our core inspiration instead of expanding into a generic social app.

What I learned

We learned that scoping is a skill. There is always more room to add more features, but simplicity is key. The issue at hand is lack of coordination, not a lack of desire to hang out, and so figuring what features to keep and cut were crucial in moving a student from intent to action. We also learned that backend design is product design: decisions about row-level security, realtime subscriptions, and how conversations tied to events directly shaped what the app could feel like. Lastly, we learned that building trust requires thinking about edge cases early, not just what we intended to happen once user joined our app.

What's next for Friends UCLA

The immediate next step is a real beta week with ideally 30-50 UCLA students using the through a tech showcase. We want to measure whether students actually complete the loop: joining an event, sending/receiving messages, and returning/finding success within a week. Based on what we learn, we'll tighten the onboarding, tune the feed ranking, and harden the moderation path before opening it up wider. If the loop holds, the longer-term question is whether the same model works beyond UCLA — any campus where students have free time and no easy way to fill it with people nearby.

Built With

Share this project:

Updates