How We Built Classory, a Multi-Tenant LMS | Incrix Blog

Building an LMS is easy if the goal is simply to upload courses and let students watch them.

Building one platform that can serve multiple academies, schools, colleges, coaching institutes and independent educators — while keeping their brands, users and data separate — is a very different engineering problem.

That was the challenge behind Classory.

Classory is a multi-tenant, white-label learning platform built and operated by Incrix in India. Instead of giving every institution a separate application, Classory allows multiple organizations to operate their own learning environments within a shared platform. Each organization gets its own workspace, users, courses, classrooms and learning experience.

This article explains the engineering principles behind Classory, the problems we focused on, and the lessons we learned while building a scalable LMS platform.

Why we built Classory

Online education has become increasingly fragmented. A student might use one application for live classes, another for recorded videos, another for tests, messaging apps for doubts, and separate payment tools for fees.

The problem isn't necessarily that any individual tool is bad. The problem is what happens when they are combined. Students have to remember multiple logins, search through messages for course links and keep track of information scattered across different systems.

Teachers and administrators experience the same problem from the other side. They may have to manage course content in one place, live classes somewhere else, tests through another tool, attendance separately, payments through another system, student communication over messaging apps — and reports across multiple dashboards.

This creates administrative work that has little to do with teaching. So our goal with Classory was not to build another LMS application. We wanted to build a unified learning platform where the major parts of the education workflow work together.

From fragmented tools to one learning environment

For students: spend less time managing the learning system and more time learning. For educators: spend less time managing disconnected tools and more time teaching.

What is a multi-tenant LMS?

A traditional single-tenant application gives every customer a separate instance of the software. This can provide strong separation, but it also creates operational complexity — every customer may need separate deployments, updates, maintenance and infrastructure.

A multi-tenant architecture takes a different approach: one application serves multiple customers, known as tenants, while maintaining logical separation between them.

In Classory, a tenant can be an academy, a school, a college, a coaching institute, a training organization or an independent course creator — each operating inside its own workspace. That's how one product can support very different education businesses, from coaching institutes to schools and colleges and course creators.

The hardest part of multi-tenancy: data isolation

Multi-tenancy introduces a fundamental engineering responsibility:

One customer must never be able to access another customer's data.

This cannot be treated as a feature that gets added later — it has to influence the architecture from the beginning. In Classory, workspace identity is carried through the application's major data operations. Every important piece of information belongs to a particular workspace: users, courses, classrooms, exams, learning resources, payments, enrollments and student activity.

So the application doesn't simply ask "Does this user have permission?" It also needs to establish "Which workspace does this user belong to?" That distinction is critical in a multi-tenant LMS.

Workspace-aware architecture

The principle is simple: a user's identity and workspace context travel together throughout the application. This creates a safer foundation for multi-tenant SaaS architecture. You can read more about how Classory approaches this on its Trust & Security page.

Designing the platform around workspaces

One of the important decisions we made early was to treat the workspace as a fundamental part of the product rather than simply another database field.

A workspace represents an organization's learning environment. Within it, the organization manages its teachers, students, courses, classes, exams, learning materials, payments and reports.

This structure also makes onboarding much simpler. Instead of creating an entirely new application for every academy, the platform provisions a new workspace within the existing product architecture — one of the fundamental advantages of a multi-tenant LMS.

White-label learning without rebuilding the platform

Educational organizations often want to build their own identity, rather than make their students feel like they're simply using somebody else's platform. So the platform needs to support each organization's identity while the underlying software remains shared.

The organization gets its own branded environment. That's what makes a white-label LMS different from simply embedding a course catalogue inside a generic website.

Designing for real education traffic

Education platforms don't experience traffic evenly through the day — usage changes dramatically with the academic calendar:

• A large batch may start an exam at the same time.
• Hundreds of learners may join a live class simultaneously.
• Students may watch a newly released lesson together.
• Assessment periods create sudden increases in activity.
• Results or assignment deadlines create short traffic spikes.

This raises an important architectural question: can the platform handle peak activity, not just average activity? Designing for average usage can make a system look efficient during normal hours while still failing during peaks.

So we designed Classory around elastic capacity: the platform handles changing demand without being permanently provisioned for its highest possible usage. It's the same serverless-first thinking we describe in why we build serverless.

Why concurrency matters for an LMS

One lesson we learned building Classory is that total registered users and active users are very different measurements.

From an infrastructure perspective, those are very different workloads. Instead of only asking "How many students does this organization have?", we also consider "How many students are actively using the platform at the same time?" That affects application requests, database activity, video delivery, exam submissions, classroom activity, notifications and real-time interactions.

Thinking in terms of concurrency gives a far more realistic picture of platform demand — and it's why Classory's plans are sized around online learners. You can see how that works on the Classory pricing page.

Protecting course content

For educators, digital content is an important business asset. A course may represent months of research, recording, editing, teaching, curriculum development and subject expertise. Simply giving students permanent public video links creates an obvious content-sharing problem.

Classory approaches course content with controlled access. Video is designed to be accessible to enrolled learners within the appropriate learning environment, rather than exposed as unrestricted public media. We use mechanisms such as:

• Time-limited access — authorization for a video doesn't remain permanently valid.
• Viewer-specific protection — content can carry identifying information about the viewer, making unauthorized redistribution easier to trace.
• Private course access — videos are consumed by learners who have access to the course, not shared as public links.

No system can completely prevent screen recording. The objective is to make casual sharing significantly harder while giving legitimate learners a smooth viewing experience. More on Classory's secure video.

Building AI into the learning experience

Instead of treating AI as a separate chatbot that sits outside the learning experience, we wanted it to be useful within the educational workflow. Classory includes Clay, an AI teaching assistant that helps learners ask questions, understand concepts, practise topics, generate questions and explain code. Educators can also use AI-assisted question generation and grading.

The engineering principle isn't simply "add AI". It's make AI useful while keeping its usage predictable. A simple question and a complex generation task can have very different computational requirements, so usage controls and resource management matter when building AI into a SaaS product.

One platform instead of multiple education tools

Architecture is only useful if it solves real problems for educators. That's why Classory combines these workflows in the same learning environment:

The purpose isn't to create the largest possible feature list. It's to reduce the number of disconnected systems an education organization has to operate.

The engineering principles behind Classory

After building and operating Classory, several principles became particularly important to us:

1. Design tenant isolation from day oneMulti-tenancy shouldn't be retrofitted after the product is built. Workspace boundaries need to shape the architecture from the beginning.
2. Design around real usage patternsAverage traffic isn't enough. Education products must account for exams, live classes, deadlines, batch launches, content releases and seasonal traffic.
3. Treat security as part of the architectureAuthentication, authorization, workspace isolation and content protection belong in product design — not after the product is finished.
4. Build for predictable operationsA SaaS platform has to be sustainable to operate. Resource usage, AI workloads, storage and video delivery costs need to be considered while designing features.
5. Keep the product experience simpleThe architecture can be complex; the user experience shouldn't be. A teacher shouldn't need to understand infrastructure to create a course. Good engineering hides complexity rather than transferring it to the customer.

What we learned building a multi-tenant LMS

The biggest lesson wasn't about any individual technology. It was about making architectural decisions early. In a multi-tenant SaaS product, seemingly small decisions compound:

Similarly, how learners consume content shapes how content is delivered — which shapes performance, security and operational cost. That's why architecture isn't simply a technical diagram. It's a collection of decisions that shape the entire product.

What this means if you're building an LMS

If you're planning to build an LMS for your organization, the first question shouldn't necessarily be "Which features should we add?" Start with the operating model:

• How many organizations will use the platform — and do they need separate workspaces?
• Will each organization have its own branding?
• How will learner data be isolated?
• What happens during peak exam traffic?
• How will course content be protected?
• How will payments and learner administration work?
• Which workflows currently require separate tools?
• What needs to scale as the customer base grows?

These decisions have a greater impact on the architecture than choosing a list of technologies. If you'd rather launch on a platform that has already solved them, you can start your own academy on Classory — or talk to us about building something custom.

Why we built Classory this way

Classory is our own product, and building it has shaped how we approach software development for clients. Our philosophy is straightforward: understand the hardest problem first. For Classory, that meant thinking deeply about multi-tenancy, workspace isolation, scalability, content protection, education-specific workflows and operational sustainability.

The technology exists to support those decisions — not the other way around. We believe a good SaaS product should be:

• Secure enough to trust.
• Scalable enough to grow.
• Simple enough to use.

That's the standard we continue to apply as Classory evolves.

Built by Incrix, powered by product thinking

Classory started with a simple observation: education shouldn't require students and teachers to constantly switch between disconnected systems. Building the solution meant thinking beyond individual features — about multi-tenant architecture, data isolation, scalability, content security, white-label experiences, education workflows, AI capabilities and operational sustainability.

Those decisions continue to shape Classory today, and they form the engineering principles we bring to every product we build:

Build the architecture around the real problem. Design for how people actually use the product. And keep improving it after launch.

Continue reading

• Incrix software development services
• Incrix education solutions
• Explore Classory
• Classory plans & pricing
• Classory Trust & Security