Rally

Calendar Page for User upcoming events
Explore Page
Friends page (Messages Page)
Friends Page (Played With)
Host an Event page
Host an Event page (Continuation)
My Events Page
My profile page ( Part 1)
My profile page ( Part 2)
My profile page ( Part 3)
Nearby me Page
Smart Watch (for fitness tracking and watch pairing)

Inspiration

Meeting people today usually means somewhere formal: the office, a networking event, a seminar. Everyone's on their best behavior, and it's hard to actually get to know someone that way. Sport does the opposite. It teaches teamwork, communication, and leadership without anyone trying to, and you find out who someone really is a lot faster on a team with them than over coffee. We wanted to build something that gets people off their phones and into that, starting in our own city. Fredericton doesn't have the constant stream of things to do that a bigger city does, so it needs this more, not less.

What it does

Rally lets people host or join sports and outdoor activities nearby, casual runs and rides up to organized team games. You browse by location and sport, join with one tap, and the listing closes itself once it's full. Because you're meeting people you don't know, safety is built into the whole flow, not bolted on: a personal QR code that only the host can scan you in with, live safety tracking during the event, and a check afterward that everyone got home okay. Once you've played with someone, you can follow them, message them, and see what they're hosting next.

How we built it

Two of us, split cleanly down the middle. One of us owned the database and the logic behind every feature: Supabase with Postgres and PostGIS for location search, row-level security so the rules hold even if someone bypasses the UI, and Postgres functions for things like the participant cap and QR check-in. The other owned the React frontend. To keep both of us moving at the same time, the frontend was built first against a mocked API with the exact function names and shapes the real one would have, so the UI never had to wait on the backend, and swapping in real Supabase calls later didn't break anything.

Challenges we ran into

Two people joining a nearly-full activity at the exact same moment could both get in and blow past the cap, so that had to be handled with a database-level lock, not a check in the frontend. We also realized partway through that any signed-in user could technically read another person's QR check-in token, which would have let someone impersonate them at check-in, so we locked that down at the column level in Postgres rather than trusting the app to hide it. And with two people building against a live schema at once, keeping the mock API contract and the real one in sync took real discipline. It also came down to a tight clock: eighteen hours is not much time to build both trust and safety into a two-sided marketplace.

Accomplishments that we're proud of

Nearly every rule that matters, who can join, who can see what, who can check in, is enforced by the database itself, not just the interface. That means the safety promises we're making aren't just UI polish. We're also proud that we built this around a real problem in our own community instead of a generic idea, and that two people managed to ship something this complete in a weekend.

What we learned

How much safer an app feels when the guarantees live in the database instead of the frontend. How to design a schema for a two-sided, location-based product with PostGIS. And how much faster two people move when they agree on an interface up front instead of building in lockstep.

What's next for Rally

Real ID verification instead of the mocked flow, real opt-in GPS tracking during events instead of simulated positions, push notifications for waitlist spots and safety alerts, and eventually a mobile app. And we'd like to grow it past Fredericton, city by city, the same way it started here.