Overview
Project: Codame
Repo: Ujjwal5705/Codame
Tech Stack: Next.js, React, Tailwind CSS 3, GSAP, Framer Motion, MUI, React Icons, EmailJS, Swiper, React Slick, Custom CSS modules + global styles
CODAME is the official website for the coding and development club at IIIT Bhopal, built and maintained by the club's own Development Team. It serves as the public face of the club—showcasing events, the team, and the club's identity to students, faculty, and prospective members.
The core challenge was not just "building a college club page." It was building a production-quality, multi-contributor codebase that stays visually consistent, performs well under animation-heavy pages, and remains maintainable as team members rotate each year.
Problem
Most college club websites suffer from the same failure modes:
- No consistent design system, leading to visual drift across pages built by different contributors
- Animation and interaction code bolted on as an afterthought, causing janky performance
- No structured contribution workflow, so direct pushes to main break things without warning
- Contact and inquiry forms require a backend that no one wants to maintain
- As team membership turns over, institutional knowledge about the codebase disappears
The result is a site that looks outdated within a semester and breaks silently when anyone touches it.
Solution
CODAME is built as a structured Next.js application that enforces consistency at every layer. The site covers:
- A public-facing club identity—about page, mission, and activity overview
- An events section showcasing past and upcoming club activities
- A team directory profiling club members and their roles
- A contact page with a working inquiry form—no custom backend required
- Smooth, purposeful animations across page transitions and UI interactions, without sacrificing load performance
Every page is built from shared components. Every visual decision flows from a single Tailwind config. Every contributor works off a branch, not main.
Architecture
CODAME is structured as a clean Next.js application with a strict separation between pages, components, styles, and assets.
-
Pages (
pages/): Each route—about, events, contact, teams—is a dedicated Next.js page. Server-side rendering ensures pages are indexable and load fast on first visit, which matters for a public club site. -
Components (
components/): All reusable UI elements live here—cards, navbars, sliders, section headers. Keeping components decoupled from page logic means any contributor can update a section without touching unrelated parts of the codebase. -
Styles (
styles/): A hybrid approach—Tailwind CSS 3 handles the bulk of utility styling, while CSS modules scope component-specific overrides cleanly. Global styles are centralized and not scattered across files. -
Assets & Public (
assets/,public/): Static media, icons, and images are separated from code. This keeps the component tree clean and makes asset swaps straightforward for non-developer team members. -
Context (
context/): React context manages any shared state that needs to cross component boundaries—keeping prop drilling out of the component tree. -
Animation Layer (GSAP / Framer Motion): GSAP handles timeline-based, scroll-triggered animations; Framer Motion handles declarative component-level transitions. Using both allows the right tool for each job without forcing one library to do everything.
-
UI & Carousel Libraries (MUI / React Icons / Swiper / React Slick): MUI provides accessible component primitives where needed; Swiper and React Slick handle event and team carousels with touch support out of the box.
-
Contact (EmailJS): Form submissions route through EmailJS, delivering messages directly to a club inbox without any server infrastructure. No backend to deploy, no credentials to rotate.
Challenges
1. Keeping a Multi-Contributor Codebase Consistent
A club website built by a rotating team of students is a consistency problem as much as an engineering one. Every contributor has a different style. Without guardrails, pages diverge fast. A strict branch-per-issue workflow, mandatory PR reviews with screenshots for UI changes, and a shared Tailwind config as the single source of design truth kept the codebase coherent across contributors.
2. Animation Performance Across Pages
GSAP and Framer Motion are both powerful—and both easy to misuse. Running heavy scroll-triggered animations on low-end devices causes frame drops that make the whole site feel broken. Animations were scoped to purposeful moments—page entry, section reveals, interactive hover states—rather than applied decoratively everywhere. GSAP was reserved for complex timeline sequences; Framer Motion handled simpler component transitions where its declarative model was cleaner.
3. No Backend, No Problem
Running a contact form without a backend is a constraint that forces discipline. EmailJS handles form-to-inbox delivery entirely client-side, removing a whole service to deploy and secure. The trade-off is limited control over delivery logic—but for a club contact form, reliable delivery to an inbox is all that's needed.
4. Survivability Across Team Transitions
Club teams change every year. The codebase has to be readable by someone who wasn't there when it was written. Clear contribution guidelines, a predictable file structure, and meaningful commit messages aren't optional extras here—they're the only way the site survives its second year.
Learnings
Building a shared codebase for a team that rotates annually forces you to write for the next person, not just for yourself. Code that "makes sense in your head" is not good enough when the person debugging it six months later has never seen it before.
The biggest shift was treating contribution structure as a feature, not overhead. Branch discipline, PR checklists, and screenshot requirements feel like friction until the day a bad push doesn't go to main—and they start feeling like infrastructure.