Platform mission & architecture

Built by students, for students.

MyBITS unifies the fragmented digital tools across campus hubs into one fast, secure, intuitive workspace per campus.

The why

  1. The chaos

    50+ WhatsApp groups, scattered Drive links

    Finding a timetable meant scrolling three years of chat. Resale happened in sketchy groups; ERP friction was a daily tax.

  2. The side-project

    A clash-free timetable builder

    One batch, one tool. It spread by word of mouth in days — proof that the pain was real and shared.

  3. Trust, not middlemen

    A verified, zero-fee marketplace

    Campus-only listings with on-campus pickup replaced the sketchy resale groups — verified peers, no commission, no spam.

  4. A voice for campus

    Forums & shared travel pools

    Anonymous-but-accountable forums and fare-split travel pools joined the stack, each sealed to its own campus.

  5. Today

    The unified Campus OS

    Academics, mess, hostel, marketplace, forums and trips — one workspace per campus, on its own verified subdomain.

Multi-tenant isolation

Every campus is a sealed vault

One institutional sign-in routes you into your campus's isolated workspace. A listing in Pilani never appears in Goa; a Hyderabad forum thread stays sealed to Hyderabad. Campus is derived from your verified email — never guessed, never crossed.

The isolation paradigm

Generic platforms pool everyone into one global database. MyBITS does the opposite: each campus subdomain is its own tenant boundary. A listing posted in Pilani never surfaces in a Goa query; a Hyderabad forum thread stays sealed to Hyderabad.

The campus you belong to is derived from your verified institutional email — never hand-set — and re-checked against your signed session on every request, so the boundary can't be spoofed by changing a URL.

  • Per-campus workspace isolation
  • Boundaries enforced on every request
  • Institutional single sign-on

Tenant partition isolation

pilani.mybitsapp.comTenant A
goa.mybitsapp.comTenant B
hyderabad.mybitsapp.comTenant C

Every request verifies the campus claim inside your signed session before any data is read.

Pilani

pilani.mybitsapp.com

Student logins
Marketplace listings
Forum threads
Mess & timetable data

Sealed — no cross-campus reads

Goa

goa.mybitsapp.com

Student logins
Marketplace listings
Forum threads
Mess & timetable data

Sealed — no cross-campus reads

Hyderabad

hyderabad.mybitsapp.com

Student logins
Marketplace listings
Forum threads
Mess & timetable data

Sealed — no cross-campus reads

Operational status

All systems operational
API response time< 42 ms
Gateway uptime99.98%
Per-campus data isolationEnforced
Build & deploy pipelinePassing

Representative targets across high-availability clusters.

Frequently Asked Questions

Origin, funding, affiliation with BITS Pilani, and how MyBITS keeps campus data isolated.

Who built MyBITS?
MyBITS is built by a small team of BITS Pilani students. It started as a clash-free timetable tool for a single batch, spread by word of mouth in days, and grew into a unified campus operating system as students kept asking for more.
Is MyBITS affiliated with BITS Pilani?
No. MyBITS is a student-led initiative and is not an official BITS Pilani application. It's not operated by or endorsed by the Institute. That's clarified in the footer and Terms of Service.
How is MyBITS funded?
MyBITS is self-funded and student-run. There is no venture capital, no ads, and no data sale. Infrastructure costs are covered by the core team. The zero-fee marketplace is philosophical, not a growth hack — students should keep what they earn.
What are MyBITS's privacy commitments?
MyBITS complies with India's Digital Personal Data Protection Act, 2023. Full details live in the Privacy Policy — the short version is: only the minimum data needed for a verified campus platform, campus-isolated at the query layer, no third-party data sale, and clear user rights over export and deletion.
How is campus data isolated in MyBITS?
Every application query in MyBITS injects a where-clause scoping data to the signed-in user's campus. The test suite asserts this on every protected route in both directions — 'this route enforces campus scoping' AND 'this route explicitly does not' — so accidental cross-campus reads become CI failures, not silent leaks.