Scholarly Case Study: Shipping a 15,000-User All-in-One LMS with WebRTC + Microservices

More on this topic: read our complete guide — AI Video Analytics for Online Learning (2026).

Why Fora Soft is publishing this case study

Fora Soft has been shipping video-first education products for a decade. Scholarly is one of the clearest examples of the pattern that repeats across our EdTech portfolio: a training business outgrowing a patchwork of third-party tools, moving to a single purpose-built platform, and hitting five-figure concurrent usage without the roof falling in.

We publish this because the question we hear most from education founders is “do we really need a custom LMS?” Sometimes no — Thinkific, Moodle, TalentLMS, Teachable will cover you. Sometimes yes — if live lectures at real scale, parent visibility and tight admin workflows are the core product, off-the-shelf hits a wall within a year. Scholarly was a yes, and the architecture, cost math and trade-offs below explain why.

If you are weighing a similar move, the same team that shipped Scholarly also ships live classrooms for BrainCert, voice and video agents on LiveKit, and custom software platforms across the rest of our client base.

Scholarly at a glance

The problem: Zoom + Discord is not an LMS

Before Scholarly, the client ran classes on Zoom, community on Discord, course materials in Google Drive, schedules in spreadsheets and billing in a separate SaaS. Every new cohort doubled the coordination cost. Four specific pain points drove the decision to build.

1. Fragmented student data. Attendance in Zoom logs. Homework in Drive. Grades in a spreadsheet. Nobody had a single dashboard to answer “how is this student doing?” Churn signals were invisible until the invoice bounced.

2. No parent visibility. Parents in the K-12 and post-secondary segment routinely ask “what is my child studying this week?”. Giving them Zoom links and a PDF schedule is not a product; it is a support ticket factory.

3. Capacity ceilings. Zoom caps out at ∼1,000 participants per meeting without enterprise licensing; it is not built for a lecture-with-whiteboard model at 2,000 students and zero IT support.

4. Admin burn. Creating a new course across five tools is a two-hour ritual. At 15,000 users with dozens of courses a week, admin hours alone justified the build in year one.

The architecture we shipped

Scholarly is a Kubernetes-hosted microservices system. The live-class plane, the content plane and the identity plane are separate services talking over GraphQL and gRPC, so a big lecture never breaks the admin console and vice versa.

Figure 1. Scholarly reference architecture: separate real-time video, content and identity planes behind a GraphQL API.

Web app (React + Next.js)

Next.js for SSR on the marketing and public-course pages, client-rendered React for the authenticated learner and teacher surfaces. A single design system covers four roles (teacher, student, parent, admin) so we do not maintain four products pretending to be one.

Services (Go + Node.js microservices)

Go for latency-sensitive services (live session orchestration, presence, scheduling). Node.js for the more I/O-heavy, fast-iteration layers (notifications, content ingest, integrations). GraphQL federation on top so the web app asks for exactly what it needs in one request.

Live video (WebRTC + LiveKit)

Active speakers (teacher and a handful of students at a time) run on a WebRTC SFU powered by LiveKit. Passive students join over DASH / HLS so we do not pay SFU costs for the long tail. Mouth-to-ear latency stays below 300ms for the active layer, 2–4 seconds for the HLS one — perfectly fine for a 2,000-seat lecture.

Recordings and content

Every live session is recorded, transcoded into an ABR ladder and pushed to a CDN-backed origin. Students catch up on their own schedule. Homework, slides and supplementary materials live in object storage with signed URLs and role-based access control.

Data and analytics

Postgres behind every service; a warehouse for analytics; Prometheus + Grafana for ops. The admin dashboard answers “who attended”, “who submitted”, “who is at risk” in a single query because that data now lives in one system.

Four roles, one platform

Teachers

Live lectures with screen sharing, a virtual whiteboard, shared course materials and text chat. Each lecture supports up to 2,000 students, is recorded automatically, and lands back in the course library without a manual upload step. Teachers see their entire schedule on a single dashboard; lecture prep time dropped from roughly 20 minutes per session (spread across Zoom, Drive, spreadsheets) to under five.

Students

Join live streams, watch recordings, take tests, submit homework and receive instructor feedback — all in one surface. Attendance, grades and progress appear in a personal dashboard. No more hunting across Zoom links, Google Docs and email threads for last week’s homework.

Parents

Parents log in to see their child’s enrolled courses, schedule, submitted homework and progress notes — read-only and scoped to the right child. This single feature collapsed a significant share of customer-support tickets (“what is happening with my kid’s course”) into self-service.

Admins and superadmins

Admins get a view-only console over courses, schedules and enrolments. Superadmins get full CRUD — creating courses, scheduling events (streams, meetings, drop-ins), uploading materials, managing users and groups, and auditing the entire catalogue. Multi-level permissions were non-negotiable for a client running multiple programs and external instructors.

Custom platform vs off-the-shelf LMS: the decision

Scholarly’s owners initially looked at Thinkific, Teachable, LearnWorlds, Moodle and Open edX. The shortlist collapsed to custom for three reasons the tools could not address:

1. Live video scale. Off-the-shelf LMSs embed Zoom / Vimeo / YouTube. None of them natively support interactive 2,000-seat lectures with whiteboard in one flow.

2. Multi-role architecture. Parent read-only access scoped to their children is not a shelf feature. It is a product.

3. Admin workflow precision. The client had a specific weekly cadence of course creation, scheduling and cross-course pricing. Bending a generic LMS to fit costs more in workarounds than building the workflows once.

The build playbook we reuse for every EdTech client

Step 1 — Role-first information architecture. Map every action to a role before touching a Figma file. Scholarly would have been unusable if we had started with “the course page” instead of “what the teacher does, what the student does, what the parent sees, what the admin can change”.

Step 2 — Pick the video plane early. WebRTC SFU (LiveKit, mediasoup) for interactivity, HLS / DASH for the passive majority, recordings to CDN. See our scalable video streaming and conferencing guide for the detailed trade-offs.

Step 3 — GraphQL contract between web and services. One round-trip per screen. Federation across services so each team owns its slice. Pays back the moment you have three product surfaces (web, mobile, admin).

Step 4 — Kubernetes from day one. Not because you need it at launch, but because the first big cohort will surface pod, resource and scaling questions you do not want to retrofit. Helm + ArgoCD for deploys.

Step 5 — Observability before analytics. Prometheus, Grafana, structured logs, alerts at 70% of capacity. Analytics come later; uptime of the live-class path cannot wait.

Realistic cost math for an LMS like Scholarly

The numbers below are what we actually quote in 2026, with Agent Engineering on both design and engineering. Traditional agencies tend to land 30–40% higher on the same scope. If you are comparing quotes and ours looks optimistic, that is why.

Infrastructure sits on top: expect USD 3–8k/mo at the 15,000-user mark for a production LMS of this shape, driven mostly by egress on recordings and SFU hosting during the live peaks.

A decision framework — should you build a custom LMS?

Q1. Is live the product, or a feature? Live-first = custom almost always wins. Feature-only = Thinkific + Zoom is cheaper.

Q2. How many concurrent students per session? < 200 = Zoom embed fine. 200–1000 = serious consideration for SFU. > 1000 = custom WebRTC + HLS hybrid is the only sustainable answer.

Q3. How many distinct user roles do you need? Two (teacher + student) is trivial. Four or more (adding parent, admin, superadmin, external instructor) is where off-the-shelf systems start forcing ugly workarounds.

Q4. How unique is your admin workflow? Standard “list of courses” fits every SaaS. Pricing that depends on seat type + season + cohort + promo does not.

Q5. Do you plan to add AI features? Auto-grading, AI tutoring, transcription, personalized paths. Off-the-shelf LMSs ship these slowly or via clunky integrations. Custom lets you pick the models, host them where you need, and control the cost curve.

Five pitfalls we see in almost every EdTech build

1. Building the “course page” before the role model. You get a good-looking demo and a product nobody can administer at scale.

2. One video service for everything. SFU for a 2,000-seat lecture is wasteful; HLS for an interactive seminar is too laggy. Use both, split by who is speaking.

3. Ignoring recordings. Attendees need async access. An LMS without searchable, indexed recordings loses half its value.

4. Weak parent or administrator surfaces. K-12 and training programs live and die by parent visibility; corporate clients live and die by admin reporting. Shipping without these is a false economy.

5. Underestimating observability. Live classes do not get second chances. Alerts at 70% capacity on SFU, transcoder and origin are the difference between a hiccup and an angry customer thread.

KPIs a modern LMS must dashboard

Quality KPIs. Live-class join success (≥ 99%), P95 active-speaker latency (< 300ms), rebuffer ratio on HLS (< 1%), end-of-session drop rate (< 2%). If any of these slide, pause new feature work and fix the pipe.

Business KPIs. Course completion rate, assignment submission rate, active learners per week, churn by cohort, parent login rate. These decide which features get priority.

Reliability KPIs. Uptime 99.95%+ on the live-class path, deploy failure rate < 2%, MTTR < 30 minutes during class hours, backup success rate 100%.

When not to build a custom LMS

Under ~500 active users and occasional live classes. Teachable / Thinkific + Zoom is a fine stack; custom would not pay back in your first two years.

Pure content library, no live. Podia, Kajabi, Thinkific. Do not over-engineer a video plane you will never use.

No product owner you can protect. A custom LMS is a product, not a project. If nobody inside your org is going to own roadmap, adoption and metrics, off-the-shelf is kinder.

Hard time-to-market under 6 weeks. Launch on a SaaS, migrate when the economics flip.

FAQ

What to Read Next

Ready to turn your Zoom + Spreadsheets into a platform?

Scholarly started where most EdTech businesses stall: third-party tools duct-taped around a good product idea. What unlocked the next order of magnitude was a single platform with clear roles, a purpose-built live-video plane, a real admin console and a parent view that removed half the support load. The technology is unremarkable on its own; the decisions around where to apply it are everything.

If your business lives on live classes, parent visibility or tight admin workflows and you are outgrowing off-the-shelf, the Scholarly playbook — role-first, hybrid video, microservices, observability early — is the one we would apply to yours. Conservative budget. Honest timeline. No vendor theatre.