← BACK TO HOME
CASE STUDYDEPLOYED

Sundarbans House

PlatformROLE — FRONTEND BUILD

The public site for an IIT Madras student house of 5,000+ members — events, study resources and announcements in one place. Built as part of the house web ops team, contributing through review on a shared codebase.

VUEVITE
sundarbans.iitmbs.org
Sundarbans House — live preview

PROOF

MEASURED, SOURCED
14 / 14
PULL REQUESTS MERGED / OPENED UPSTREAM
GitHub search API — repo:SundarbansWebOps/Frontend author:Anuraj-dev
5,170+
ACTIVE HOUSE MEMBERS
Figure published on sundarbans.iitmbs.org
500+
EVENTS HOSTED
Figure published on sundarbans.iitmbs.org
OPEN REPOSITORY EVIDENCE (1)
40+
CITIES CONNECTED
Figure published on sundarbans.iitmbs.org

THE PROBLEM

WHAT NEEDED SOLVING

Sundarbans is one of the houses of the IIT Madras online degree, and an unusually active one — events, resources and announcements move constantly for a membership in the thousands. Spread across chat groups and documents, that activity reaches whoever happened to be looking at the right moment and misses everyone else, and a member who joins later has no way to find what already happened. A house that busy needs a place that holds its own record. The work here was joining the house web ops team as a contributor and helping make that site the place the house actually points people to.

THE APPROACH

HOW IT WAS BUILT

The front end is Vue and Vite, and it was built from scratch rather than adapted — the current site is that build. It is worth stating plainly how the history looks, because it does not match the work: development happened in a separate working repository, and the finished, reviewed code was then uploaded into the house organisation's repository by the web admin, so the commit trail there begins after the fact rather than at the beginning. What the public record does show is the part that continued afterwards — changes landing as reviewed pull requests into a shared repository owned by someone other than its author. That is the discipline this project actually taught: writing code to be read and approved by other people, for an audience that was already using it.

FIELD NOTES

PROBLEMS HIT — AND RESOLVED
  1. 01

    CODE THAT HAS TO PASS SOMEONE ELSE

    Building something nobody reviews and building something a web admin has to approve before it reaches five thousand people are different jobs. Every change is judged on whether it fits the house's conventions as much as on whether it works, which rules out the clever solution that cuts against the existing structure. The trade is real: slower to land, and far harder to break a site other people depend on.

  2. 02

    A SITE FOR FIVE THOUSAND PEOPLE WHO DID NOT ASK FOR IT

    A house site is used by a membership with every level of technical comfort, on whatever device they own, mostly while looking for one specific thing. That rules out interfaces that need explaining and puts the weight on making events, resources and announcements findable rather than on anything expressive. The audience is captive and unforgiving in the specific sense that they will simply go back to asking in the group chat if the site does not answer faster.

CAPABILITIES

WHAT IT ACTUALLY DOES
  • Public site for an IIT Madras house with a membership in the thousands
  • Events, resources and announcements consolidated into one findable place
  • Front end built from scratch in Vue and Vite, as a member of the house web ops team
  • Changes shipped through pull request and review on a repository owned by the house
  • Live for a membership that was already using the site while it changed