Web · 2026
SANKALP — a student platform of thirteen applications
The official website and student platform of SANKALP at BITS Pilani Hyderabad, which I both built and chair — thirteen independent applications, sixteen databases and 141k lines of framework-free PHP, live and in daily use.
sankalpbphc.com is the official website and student platform of SANKALP at BITS Pilani Hyderabad Campus. I am both its developer and the chairperson of the organisation it serves — which means I have the unusual privilege of building a system and then living with it as a user, alongside everyone else, every day.
It is the largest thing I have built: thirteen independent applications behind one front door, live and in continuous daily use.
The shape of it
| | |
|---|---|
| Application code | ~964 PHP files, ~141k lines |
| Databases | 16 — one per ownership boundary |
| Minisites | 13 independent sub-apps |
| Stack | PHP 8, MariaDB, Apache |
| Sign-in | Google OAuth 2.0 — no password is ever stored |
| Front end | Hand-written CSS and JavaScript. No framework, no build step, no bundler |
That last row is the defining constraint. There is no Laravel here, no npm, no bundler and no build step — procedural PHP behind a single front controller, and CSS and JavaScript written by hand. Most of what is architecturally interesting about this project is what you have to do deliberately, and keep doing, to hold a system this size legible when no framework is holding it up for you.
Thirteen applications, not one
The student platform is not a single application with thirteen features. It is thirteen genuinely independent sub-apps, each with its own database, its own routing, its own assets and its own administration model.
- Academic resources — course materials, grades, reviews, a wiki and a doubts board, synchronised against a shared drive as the source of truth.
- Library — a catalogue of 41,938 books with a purpose-built search engine, course-linked shelves and student reviews.
- Course Planner — a timetable builder whose generator searches for clash-free schedules by backtracking, rather than asking a student to find the conflicts themselves.
- Organisation management — by far the largest, with its own kernel, thirty modules and a few hundred routes: people, offices, groups, tasks, meetings, documents, elections and selections, internal communications, the deliberative chambers, the Election Commission and the Court of Duty.
- Buy & Sell — a used-textbook marketplace for the campus.
- Sahayta — a grievance and protected-disclosure platform, deliberately built as two parallel systems that share only their visual chrome.
- Pulse — student-government transparency: representatives, promises and referenda.
- FAQ — a searchable campus FAQ with an assistant that answers strictly from a bank of verified articles and from nothing else.
- Fests — event and fest management, with planning, live scores and an arena view.
- Noticeboard — campus notices with streams, reactions and scoped moderation.
- News — an internal editorial digest with a full editorial workflow and a four-level editor ladder.
- Compass — a curated directory of external resources and an admin-curated document library.
- Games — an arcade hub, a members-only mock-trial competition, and a social lobby.
Splitting them this way was the decision that made everything after it possible. A minisite can be extended, redesigned or rewritten on its own schedule without any of the other twelve needing to know. Nothing about a book catalogue and its search ranking has anything to do with grievance intake or a fest's live scoreboard, and the architecture agrees with that rather than arguing with it.
Grounding an assistant properly
The campus FAQ ships an assistant, and the rule governing it is the one I would carry to any other project: it answers only from the bank of verified articles behind it, and that restriction is structural — a property of what the system is able to hand the model — rather than an instruction in a prompt asking it to behave.
The distinction matters enormously. A prompt that says "only use the provided context" is a request. An architecture in which no other context exists is a guarantee. For a service answering students' questions about their own institution, only the second one is worth shipping.
Two axes of authority
Running an organisation is not the same problem as administering a website, and the platform models them as two separate questions rather than flattening them into one list of permissions. What portal a person may enter is one axis; what they may do once inside the administrative portal is another, and it is governed independently.
Several minisites then layer their own administrative model on top — a library needs different custodians from a grievance platform, and pretending otherwise would produce a permission scheme that matched nobody's actual practice. The platform allows that divergence deliberately, and documents each one.
Underneath all of it, only the document root is reachable by URL. Application code, dependencies, outbound integrations and user uploads all sit outside Apache's reach entirely.
The documentation is part of the system
Roughly twenty thousand lines of prose across about fifty files, kept beside the code it describes rather than in a wiki that quietly drifts out of date.
Each major folder documents itself with the same two filenames: one file states the exact, verifiable contract for engineers, and another explains the same component in prose for the people who actually use it. An index at the root maps a task to the single document that answers it, so no one — including me, six months later — has to re-derive from source something a document already states exactly.
For a student organisation this is not documentation for its own sake. Committee members change every year. A platform this size that only one person understands is a platform with a one-year lifespan, and writing it down is the difference between something that gets inherited and something that gets abandoned.
What I would keep
Three decisions have earned their place, and I would make all three again: independence between sub-apps, so that scale never becomes fragility; structural constraints over prompted ones, wherever a language model touches something that matters; and documentation written for two audiences at once, because the engineer and the office-holder need the same system explained in genuinely different registers.
A platform overview covering the architecture and each of the thirteen applications in more depth is available as a PDF.