SANKALP — a student platform of thirteen applications

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 gives me the unusual privilege of building a system and then living inside 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

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.

What a framework would have decided for you

A framework is, more than anything else, a set of decisions already made. Its directory layout, its routing, its idea of where a boundary between two features belongs — all of that arrives settled, and the cost of that convenience is that you can build something very large without ever having articulated why it is shaped the way it is.

Without one, every one of those decisions has to be made explicitly, written down, and then actually held to across a hundred and forty thousand lines. That is more work. It is also the reason I can account for the shape of this system rather than describe it. Nothing here is arranged the way it is because a generator put it there.

The discipline that makes it survivable is repetition: the same layout in every minisite, the same conventions for routing and assets, the same two documentation files in every major folder. Once a pattern is genuinely uniform, a person can learn it in one place and then read anywhere in the codebase — which is exactly what a framework buys you, arrived at by agreement rather than by import.

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.

The database boundary is what makes the independence real rather than decorative. Sixteen databases, drawn along lines of ownership, mean that two applications cannot quietly grow a dependency on each other through a shared table — the sort of coupling that is invisible at the time and structural by the time anyone notices. If two things need to know about each other here, that has to be stated, not stumbled into.

Two of them worth opening up

A catalogue of forty-two thousand books is past the size where a plain substring match is a search engine. Students look for a book by half a title, by an author's surname, by a course code, or by the thing the book is actually about, and those are four different queries wearing the same box. The search is purpose-built for that rather than delegated to a LIKE clause, and the shelves are linked to courses so the catalogue can answer the question a student actually has — what do I read for this course — instead of the one they typed.

Building a timetable is a search problem, and treating it as one is the whole difference. The naive version of this feature shows a student their options and lets them discover the clashes themselves, one disappointment at a time. The generator instead searches the space of possible schedules by backtracking and returns the ones that work. The student's job becomes choosing among valid timetables rather than hunting for a valid one, which is a much better use of the week before registration.

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.

It also sets the ceiling honestly. The assistant is exactly as good as the article bank behind it, which means improving it is editorial work rather than prompt work — and that is a far healthier place for the effort to go.

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.

Building it and living in it

Chairing the organisation while maintaining its platform collapses a distance that normally exists in software, and it changes what gets built. I do not receive a feature request as a ticket with the context stripped out of it; I am usually in the room where the need appeared. And I cannot ship something merely adequate and move on, because I will be the one using it at the next meeting, along with everyone I asked to trust it.

The most useful consequence is a kind of enforced honesty about scale. It is easy, building for an organisation you are not part of, to design for the org chart rather than for the Tuesday evening when four people are trying to finish something before a deadline. Using your own system weekly makes the second one much harder to ignore.

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.

Two audiences, deliberately, because they need genuinely different things from the same explanation. An engineer needs the contract: what this component guarantees, what it expects, what it will do at the edges. An office-holder needs to know what the thing is for, what it will and will not let them do, and which screen to open. Writing one document and hoping it serves both produces something that serves neither — too vague to implement against, too technical to act on.

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. The documentation is, quite literally, the succession plan.

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.

Where it goes next

The interesting future work is in depth rather than breadth. Thirteen applications is the right number — the campus does not need a fourteenth so much as it benefits from the existing ones getting richer, and the architecture is set up so that any one of them can be taken further without the others being touched at all.

The assistant is the clearest example. Its quality is bounded by the article bank rather than by the model, so it improves through editorial work; and at a much larger bank than the campus currently needs, the same structural guarantee would sit on top of retrieval instead of a curated set, with nothing above it changing. That is the shape I want every part of this to have — a component that can be deepened in place, on its own schedule, without the rest of the platform needing to agree.

A platform overview covering the architecture and each of the thirteen applications in more depth is available as a PDF.