JVBI Connect — one platform for a whole campus.
A learning platform and campus operations system for Jain Vishva Bharati Institute, the deemed university in Ladnun. Students, faculty, wardens, hostelers and administrators each get their own app or portal — all five talking to a single API, each locked to what their role is allowed to see.
- Client
- Jain Vishva Bharati Institute
- Scope
- LMS + campus operations
- Surfaces
- 2 mobile apps, 2 portals, 1 console
- Status
- Delivered & in production
A university doesn't stop at coursework.
The obvious ask was a learning management system: courses, video lessons, assignments, quizzes, results. That part was never in doubt.
The harder truth is that a campus runs on everything around the coursework. A student's day involves hostel leave, mess fees, a library book, an ID card, an internship form and a support ticket. A faculty member's involves attendance, appraisal paperwork, notesheets and mentee sessions. A warden's involves who signed out and hasn't come back.
Running those on separate systems — or on paper — is what makes campus software frustrating. So JVBI Connect was built as one platform covering both: the LMS at the centre, and the operational subsystems around it, sharing one login and one source of truth.
The architectural bet: one API, many faces. Every surface is a different view onto the same data, so a mark entered once is the mark everyone sees — no syncing between systems that disagree.
Five audiences, five front doors, one backend.
Rather than one app with everything hidden behind permission checks, each audience gets a product shaped around what they actually do all day.
Student app
The one most people use — coursework in a pocket.
- Courses, subjects, topics and content
- Video player and in-app PDF reader
- Assignments, quizzes and results
- Attendance, syllabus, past-year papers
- Fees, ID card, certificates
- Hostel leave, notices, support tickets
- Mentor sessions and internships
Staff app
For faculty and wardens who are rarely at a desk.
- Attendance marking and course content
- Quizzes and question papers
- Hostel management and leave approvals
- Library, store and asset requests
- Notesheets and appraisal
- Meetings and vehicle management
Student portal
The same coursework on a full screen, for real study sessions.
- Video lessons and course browsing
- Assignment submission
- Quizzes and progress dashboards
- Discussion forum and blog
- Chat and meetings
- Mentor and feedback
Faculty portal
Where teaching actually gets administered.
- Content authoring and approvals
- Assignment submissions and grading
- Attendance and scheduled classes
- Results and enrolment summaries
- Teaching summary and mentee progress
- Plagiarism reports on submissions
Admin console
The control room for the whole institute.
- Programmes, courses, semesters, subjects
- Drag-and-drop content and topic ordering
- Faculty, students and reporting managers
- Roles and granular permissions
- Hostel, inventory and vehicles
- Notices, banners, popups, tickets
- Reports, results and login history
Media migration worker
A single-purpose tool for a problem worth solving properly.
- Copies the entire media library between accounts
- Runs entirely inside the edge network
- Zero egress cost on roughly 80 GB
- Token-gated so it can't be triggered by strangers
- Rewrites stored asset URLs afterwards
What's actually inside
The backend carries just over a hundred controllers across three role domains. These are the subsystems they add up to.
The parts that took the thinking.
Five separate role guards
Student, faculty, admin, warden and hosteler each have their own authentication middleware, so a token issued for one role simply cannot traverse another's routes.
Permissions from the database
Admin rights aren't hardcoded. Each capability is a row that can be granted or revoked per administrator, so the institute changes who can do what without a redeploy.
An audit trail you can replay
Every admin action is logged with a trace id, the route, the payload and the response — plus a reproducible command for the exact request. Writes are deferred so logging never slows a response.
Direct-to-storage uploads
Course video goes straight from the browser to object storage on a short-lived signed URL with a server-side file-type allowlist — large uploads never tie up the API.
Load-tested, not hoped-for
A k6 suite exercises the platform at steady state and beyond — 1,000 concurrent students with 100 faculty, then pushed to double that to find where it breaks before term does.
Meeting the campus where it is
The platform bridges to systems the institute already runs — the university management system for fees, an exam platform, the library catalogue and a self-hosted chat server — via single sign-on rather than replacing them.
We wrote the security review and handed it to the client.
A platform holding student records, results and fee data should be able to explain itself. So alongside the build we produced a security documentation deliverable for the institute — a written account of every control in place and how it is enforced.
It covers transport security, token handling and expiry, password hashing with identical responses for wrong-user and wrong-password (so the login form can't be used to discover who has an account), the role guards and permission model, rate limiting on authentication and password reset, login auditing with IP and device, the admin activity trail, hardened HTTP headers, and parameterised database access throughout.
That last one is worth naming: the backend uses parameterised SQL everywhere rather than an ORM. It's a deliberate choice — full control over the queries behind a hundred-plus controllers, with injection protection built into how every one of them is written.
Why it matters commercially: when an institute is asked how its student data is protected, it should have a document to hand rather than a phone call to make.
Scale of the build
Delivered, then extended.
The original platform — mobile apps, both portals, admin console and backend — was delivered and put into production. The institute then came back for a second phase of new modules on top of it.
That round added a discussion forum, in-app chat, learner sub-groups, assignment completion tracking for faculty, sequential unit unlocking so a student clears one unit before the next opens, quiz pass thresholds with retakes, and a blog module.
Repeat scope from an existing client is the outcome we care about most. It means the first delivery held up under real use.
What it's built on
Mobile
- React Native (Android + iOS)
- Redux Toolkit · React Navigation
- Native video & PDF viewers
- Keychain-backed token storage
- Firebase Cloud Messaging
- Direct-to-R2 uploads
Web
- Next.js 15 · React 19
- Tailwind CSS · Radix UI
- Zustand · React Hook Form + Zod
- TipTap editor · dnd-kit ordering
- Video.js · PDF.js reader
- Recharts dashboards
Backend & Infra
- Node.js · TypeScript · Express
- MySQL, parameterised SQL
- JWT auth · Helmet · rate limiting
- Cloudflare R2 object storage
- PM2 cluster mode · cron services
- Puppeteer PDF certificates
Running an institute on five systems that don't talk?
We build campus platforms that cover the coursework and everything around it — and integrate with what you already have rather than forcing a rip-and-replace.