Building Jversity: a multi-tenant educational LMS platform

Screens from Jversity.

Context

Jversity is our own product: a hosted platform on which a coaching institute or a single teacher runs live classes, online courses and a blog under their own brand, each service on its own subscription. Every institute is a tenant with its own domain, branding, students and payment account. We designed it, built it, and we operate it every day.

Building for ourselves meant we could not hide behind a client's requirements. Every shortcut would be ours to live with.

What made it hard

Four things, each of which we have written up properly elsewhere. The short version:

Tenant isolation had to be structural, not a rule people remember. Every shared medium carries the organisation explicitly, and we audited the platform against that one rule before any external tenant signed up. Enforcing tenant isolation beyond the database.

Payments run on each tenant's own gateway, so the money never touches us. That is right for them and for GST, and it meant building a provider-neutral spine underneath four providers. Payments architecture for multi-tenant platforms.

Live classes come in three formats, and they are genuinely different products rather than one feature with a switch. Each is now documented on its own: 1:1, batch and broadcast.

Two planes, not one. The tenant-facing application and the operator console are separate deployments with separate routes and separate boot graphs, so an internal tool can never leak a public endpoint. This is the constraint that shaped the most code and the one nobody asks about until it has already gone wrong somewhere else.

What we did

We built the backend as a modular NestJS service with a separate worker for recordings and reconciliation, a Next.js tenant application that resolves the organisation from the hostname, a separate operator console, and a mobile app. Storage and delivery moved to a platform-provided layer so an institute never has to configure a bucket. Email is platform-provided too, with each institute verifying its own sending domain.

Everything deploys through a single promotion path, documented in runbooks a new engineer can follow, and is monitored with alerts that page a person.

What's next

An org page builder replacing the fixed landing-page templates, a self-hosted edition for institutes that must keep data on their own infrastructure, and a mobile checkout that matches the web one.

What does success look like for your project?

Tell us what you are building and where it is stuck. We reply within one business day with a straight answer on fit, approach and cost.