LoopIn

Overview

LoopIn is a campus app I built for RCCIIT, my college, while leading GDG on Campus. It pulls three things students kept asking about into one place: what's happening on campus, who can teach them a skill, and quick answers about campus life.

The code is in a private repository, so this write-up covers the product and its overall shape.

The problem

Campus life was spread across WhatsApp groups, club Instagram pages and notice boards. Club leads posted the same event in five places and still couldn't tell who was coming. Students who wanted to learn something from a senior had no way to find one.

What I built

• Event hub: clubs create and manage events with a capacity; students browse them and RSVP, and each event shows live attendance against its limit. AI-powered recommendations surface events that match a student's interests.
• Skill exchange: students list what they can teach and what they want to learn, and an AI matcher pairs mentors with learners.
• Campus assistant: an AI chat that answers questions about campus resources and helps people find their way around the app.
• Chat: public and private channels for peers and clubs.
• Club admin tools: club leads create events and watch RSVPs without a spreadsheet.

Architecture

A Next.js app on Vercel talks to managed backend services for auth, data and AI, so there's no server of my own to run.

flowchart LR
  subgraph client["Browser"]
    ui["Next.js app"]
  end
  subgraph vercel["Vercel"]
    ssr["Pages and server actions"]
  end
  subgraph backend["Managed services"]
    auth["Auth"]
    db[("Document database: events, RSVPs, skills, chats")]
    ai["Gemini: recommendations, matching, assistant"]
  end
  ui --> ssr
  ui -->|"sign in"| auth
  ssr --> db
  ssr --> ai
  ai -->|"reads context"| db

System design

What happens when a student RSVPs to an event that has a capacity.

sequenceDiagram
  participant S as Student
  participant A as LoopIn app
  participant DB as Database
  S->>A: Tap RSVP on an event
  A->>A: Check the student is signed in
  A->>DB: Read attendee count and capacity
  alt event is full
    A-->>S: Show event full
  else seats left
    A->>DB: Add the RSVP and increment the count together
    DB-->>A: Updated count
    A-->>S: You're going, with the new count
  end

Decisions & trade-offs

• Managed services over my own backend. A student-run platform needs to keep working when its builder graduates. With no servers to patch, the next GDG lead can keep it running.
• One app instead of three. Events, skills and the assistant share one sign-in and one profile, so a student's interests feed both event recommendations and mentor matching.

What I'd do next

• Hand ownership of each club's events to the club, with roles, so moderation doesn't depend on one admin.
• Add notifications for events a student has RSVP'd to.