AI Learning Platform in 2026: Lessons from Building Scholarly for 15,000 Users

Why Fora Soft wrote this playbook

We have built edtech products since 2005 — virtual classrooms, live lecture rooms, AI tutors, proctoring systems, corporate L&D portals. Scholarly, a learning platform we shipped for an Australian client, now serves 15,000 active learners and runs live lectures with up to 2,000 students per session on WebRTC and LiveKit. The numbers, architecture choices and compliance decisions in this guide come straight from that project and a dozen like it.

We ship with Agent Engineering — our senior engineers drive AI agents across design, code generation, test creation and review. That lets us compress a classical AI-LMS MVP from 7–9 months to 4–6 months at the same quality bar, with a smaller team. See the full approach on our eLearning and virtual classroom development page and in our AI integration service.

This article tells you what an AI-powered learning platform like Scholarly actually includes under the hood, how to decide between build and buy, where AI adds measurable value, and what it realistically costs — so you stop arguing about features and start shipping the right thing.

What Scholarly is, in one look

Scholarly is an all-in-one online learning platform we designed for an Australian education provider that had outgrown a stack of Zoom, Discord and ad-hoc collaboration tools. It unifies live lectures, recorded content, course management, assignments, testing and parental access into one product and today serves 15,000 users.

Four roles, one platform:

• Teachers run live lectures up to 2,000 students per session with screen sharing, virtual whiteboard, text chat and lecture recording. Every recording is automatically attached to the course.
• Students join live streams, watch recordings, work through materials, take tests, submit homework and receive feedback in one place.
• Parents see their children’s courses, schedules, progress and study materials — a detail K-12 buyers always ask for.
• Admins and super-admins create courses, schedule events, upload materials, manage users and run the directory.

The rest of this guide generalizes from Scholarly and the broader 2026 edtech landscape to answer the question most founders actually ask us: how do I build something like this, and where does AI belong in it?

The AI-in-education market in 2026, briefly

Global edtech sits around $215 billion in 2026 and grows at roughly 13% CAGR. The AI slice grows much faster — published forecasts put AI-in-education at ~$9–10 billion in 2026 expanding at 34–42% CAGR through 2030. Adoption has flipped from experiment to default: 92% of students report using AI for learning, 60% of teachers use AI at least weekly, and 83% of institutions plan to deploy AI teaching assistants by end of 2026.

Three segments dominate:

• K-12 — highest compliance friction (FERPA, COPPA, parental consent). Parents as a first-class user role is a hard requirement, not a nice-to-have.
• Higher education — research and teaching assistants, plagiarism / AI-written work detection, integrity auditing.
• Corporate L&D — time-to-competency, compliance training, skill-path recommendations. This is the fastest-growing slice.

Practical take: the edtech that wins in 2026 combines a solid LMS core with three or four well-integrated AI capabilities — not a dozen half-baked features.

Build vs buy: how to decide before you write a line of code

Buying an LMS and layering AI on top is the default answer for ~80% of teams. Build custom when one of four things is true: your pedagogy is non-standard, your scale is extreme, your compliance profile is unusual, or your product needs a media / AI pipeline that off-the-shelf LMSs cannot host. Scholarly falls into all four — 2,000-seat live classes, custom course model, Asia-Pacific data residency, WebRTC-first lecture UX.

For a broader discussion of the build-vs-buy tradeoff in video-heavy products see our Vonage Video API alternatives post.

AI capabilities that actually move the needle

Seven capabilities account for almost all the ROI we see on AI-LMS projects in 2026. Pick the three or four that fit your learners, skip the rest.

Adaptive learning paths

Behavior DB plus a decision model that sequences content, drops prerequisites when mastered and surfaces remediation when a learner stalls. Published case studies (Squirrel AI, Carnegie MATHia, Duolingo) show 10–34% faster time-to-proficiency versus non-adaptive cohorts. Biggest pitfall: the cold-start problem — adaptive logic only kicks in after ~10 learner interactions, so design a strong default path first.

AI tutors and assistants (RAG-based)

LLM-powered chat grounded in your course content via Retrieval-Augmented Generation (RAG). The tutor sees the lesson, the textbook chapter and the learner’s recent answers, then responds. Khanmigo and LearnLM set the bar: Socratic style, no spoon-feeding of answers. Stack: vector DB (Qdrant, Weaviate, Pinecone) + LLM (Claude, GPT-4, Llama 3) + guardrails + citation anchors.

Automated grading and plagiarism / AI-write detection

Rubric-based grading for essays, code and math. Detection for copy-paste and AI-generated submissions (Turnitin Clarity, HackerRank). Honest caveat: AI-write detection is still imperfect — up to 94% of AI text slips through some tools, and false positives disproportionately hit non-native English writers. Use detection as a signal for a human-in-the-loop review, not a verdict.

AI content and quiz generation

Drop-in quiz item banks generated from lecture transcripts or uploaded PDFs. Cost is negligible ($0.01–$0.05 per question at scale). Risk is copyright bleed — if you train on unlicensed content you inherit the liability. Generate from licensed or user-owned content only.

Speech-to-text, translation, live captions

Whisper-class models for transcription, Verbit-class providers for live captions, and translation layers that bring a lecture to non-native speakers. This also wins you WCAG 2.2 compliance almost for free. For video translation architecture we keep a separate playbook.

Predictive at-risk scoring

Event-stream analytics that flag learners likely to drop out 2–4 weeks before they do, so advisors can intervene early. In corporate L&D this is the single capability buyers pay the most for — it converts learners to completions.

Video analytics and engagement signals

Track who actually watched, when they rewound, where they skipped. We covered the implementation in detail in our AI video analytics for online learning guide.

Reference architecture: the Scholarly stack

Scholarly’s actual tech stack, unchanged:

• Frontend — JavaScript, React, Next.js. Server-side rendering for marketing and course-listing pages, client-side for the live lecture room.
• Backend — Go and Node.js microservices. Go handles the performance-sensitive paths (auth, live session routing, media metadata); Node.js handles content, notifications and integrations.
• Live video — WebRTC + LiveKit, with DASH/HLS fallback for playback. LiveKit scales cleanly to 2,000 participants per room. See our LiveKit expertise page for the wider pattern.
• API layer — GraphQL. Lets the client ask for exactly the fields it needs and reduces round trips in the complex course-details screens.
• Infrastructure — Kubernetes for microservice orchestration, plus a managed Postgres cluster, object storage for recordings and a CDN for static assets.
• AI layer (optional extensions) — LLM provider (Claude / GPT / Llama), vector DB (Qdrant or Weaviate) for RAG, Whisper for transcription, and a feature store for adaptive personalization.

The pattern scales. Swap LiveKit for mediasoup or Kurento if you need server-side media processing (see our Kurento Media Server guide). Swap Postgres for a managed cloud equivalent. Swap GraphQL for REST if your team prefers. The core decomposition — separate live-video plane from content plane — is what matters.

Live lectures at 2,000 students per session

Running a 2,000-seat live lecture on WebRTC is not “just use Zoom in an iframe”. It demands three architectural calls that trip up 90% of teams on their first try:

1. Broadcaster model, not mesh. Teachers broadcast; students subscribe. A single teacher sends one (or a handful of simulcast) tracks to an SFU; the SFU fans out to students. Students do not send video unless called on, which keeps the total stream count linear, not quadratic.

2. Publish-subscribe for interactions. Chat, raise-hand, polls and reactions ride a dedicated pub/sub channel (Redis, NATS or a managed equivalent), not the video plane. Congestion on chat must never degrade video quality.

3. HLS fallback for the long tail. Tablets, old Android devices and restrictive networks sometimes cannot hold a WebRTC session for 90 minutes. Give them a live HLS or DASH stream with 5–10 seconds of added latency; bad video is better than no video.

For the detailed media-server trade-offs see our P2P vs MCU vs SFU explainer and the 2026 WebRTC architecture guide.

Compliance: GDPR, FERPA, COPPA, WCAG 2.2, SOC 2

Compliance is architectural. Bolting it on at launch is the single most expensive mistake we see.

The 2026 COPPA amendment is the big one — if your product serves any US learner under 13, the new rule tightens verifiable parental consent and bans algorithmic content targeting by default.

Cost model for a custom AI learning platform

Numbers below are ranges we use on scoping calls. With Agent Engineering we routinely ship at the lower end of each band, sometimes below. Every project is different — use these as planning anchors.

Plus 10–20% for third-party line items we always itemize: content and assessment authoring, security audits, WCAG review, SSO integration, SCORM/xAPI conformance testing. For a per-minute vs self-hosted trade-off on the media side see our LiveKit vs Agora cost analysis.

Mini case: Scholarly’s 12-month build

An Australian education business approached us running its operations on Zoom for lectures, Discord for chat, a SaaS LMS for assignments and Google Drive for materials. They had ~3,000 users and were bleeding 20+ hours a week in admin overhead syncing across tools. They wanted one platform, their pedagogy, and room to grow to 15,000+ users.

Our 12-month plan delivered a custom LMS on Go/Node microservices behind a React/Next.js frontend, WebRTC plus LiveKit for live lectures scaling to 2,000 students per room, GraphQL for the complex course views, and Kubernetes for the runtime. AI agents in our delivery pipeline generated roughly 70% of the service scaffolding, OpenAPI specs and tests in parallel with senior engineer review, which is how we held the timeline.

Outcome: 15,000 active users today, up to 2,000 students in a single live lecture, admin hours cut from 20+ per week to under 4, lecture recording pipeline fully automated. Book a 30-minute call and we will sketch a similar path for your audience.

A decision framework — ship in five questions

Run these before you commit to build or buy. “No” to Q1 and Q2 means a SaaS LMS is almost certainly the right call.

1. Is your pedagogy standard or proprietary? If your learning design maps onto “courses with videos and quizzes”, any major LMS handles it. If your curriculum needs branching logic, unusual assessment types or a product-level UX, custom becomes attractive.

2. What’s your concurrency ceiling per live session? Under 500 is easy on most platforms. 500–2,000 pushes you to a WebRTC-first design like Scholarly. Above 10,000 you are in hybrid WebRTC + HLS territory.

3. Which compliance regimes apply? GDPR, FERPA, COPPA, accessibility, SOC 2 — each adds 4–12 weeks to the build. The union of your regimes tells you your minimum realistic timeline.

4. Where does AI sit in the learning loop? If AI is the product (autonomous tutor, fully adaptive), it has to be native. If AI just augments existing content, you can start with an LMS plus an LTI plugin.

5. Do you have a DevOps / SRE on the team? Custom infrastructure wants someone who owns Kubernetes, CI/CD, DR drills and log aggregation. No one in that role? Stick with a managed LMS until you hire.

Five pitfalls we see on AI learning platform projects

1. Shipping an AI tutor with no RAG. Plain LLM in a chat window hallucinates course content within the first hour. Always ground the tutor in your materials via RAG, always include citation anchors, always have a human review path for disputed answers.

2. Treating detection as a verdict. AI-write and plagiarism detectors have high false-positive rates — especially on non-native English. Use them as triage signals that open a human review, never as grounds for automatic sanctions.

3. Ignoring the cold-start problem. Adaptive paths need ~10 learner interactions before they personalize well. Design a strong default curriculum and a warm-up phase; do not launch with “100% adaptive” copy.

4. Bolting compliance on at the end. GDPR right-to-erasure requires a soft-delete pipeline across every service. FERPA needs auditable record access. WCAG demands captions in your live pipeline. Retrofitting each of these doubles the work.

5. Confusing personalization with engagement. Adaptive content alone plateaus completion rates at 60–70%. Gamification, social proof, cohort pressure and deadlines move the number further. Plan for both.

KPIs: what to measure on an AI learning platform

Quality KPIs. Course completion rate ≥ 70%, 30-day knowledge retention ≥ 65%, AI-tutor answer-accuracy (spot-audited) ≥ 85%, caption accuracy ≥ 93%. Below these, you are adding noise, not value.

Business KPIs. Time-to-competency for role-based tracks (baseline: cut by 20% vs non-adaptive), NPS ≥ 45, cost per completed learner (target: ≤ $5 for corporate L&D, course-dependent for paid edtech), monthly active learners, paid-to-trial conversion.

Reliability KPIs. Live-lecture join success rate ≥ 98%, lecture recording success rate ≥ 99.5%, P95 content-page TTFB < 800ms, uptime ≥ 99.9%. Alert on any of these and you catch bad deploys before users do.

How we integrate AI into an existing LMS

Most clients do not need a full Scholarly rebuild — they need AI capabilities on top of the platform they already run. Our default engagement for that is 6–10 weeks:

• Week 1–2 — audit existing content, pick two or three AI capabilities with the highest measurable ROI for your learners.
• Week 3–6 — stand up the RAG index, wire up the LLM provider, ship an MVP tutor or auto-grader as an LTI plugin or native module.
• Week 7–10 — evaluate on real learner data, tune prompts, close the loop with human-in-loop review, harden for compliance, roll to production.

For a deeper dive into smart-tutor design see our AI tutoring systems for educators guide.

Security patterns that pass procurement

Every edtech procurement deck in 2026 asks the same eight questions: where does data live, who has access, how is it encrypted, how do you handle an incident, what happens if a learner opts out, how is the LLM provider reviewed, where is the audit log, and how often do you pen-test. Have an answer ready before the call and your deal closes weeks earlier.

Baseline patterns we put into every Scholarly-class build: central identity provider with SSO (SAML, OIDC, LTI 1.3 as needed), encryption at rest and in transit with rotation, per-tenant data partitioning, immutable audit logs, a dedicated “AI-review” role that sees tutor transcripts, automated data-retention policies aligned with GDPR/FERPA/COPPA, and a written incident-response runbook rehearsed quarterly.

For LLM-specific risks, maintain a prompt-injection test suite in CI, keep a “system prompt” allow-list, redact PII before it hits the LLM provider, and log every AI interaction with retention that matches your FERPA/GDPR timelines. Our WebRTC security primer covers the media plane in parallel.

Which LLM should power your tutor?

No universally right answer. We pick based on three axes: reasoning quality for your curriculum, data-residency and privacy, and cost at your expected query volume.

• Claude (Anthropic) — excellent Socratic tuning, strong at long-context reasoning on course materials, solid safety profile. Our default for student-facing tutors.
• GPT-4 / GPT-4o (OpenAI) — broad capability, best-in-class multimodal. Good for content generation and speech-first tutors.
• Gemini (Google) — strong on factuality and integration with Google Workspace if your institution runs it.
• Llama 3 / Mistral (self-hosted) — when data must stay in your VPC and you have the GPU budget. Good for RAG-heavy tutors where reasoning needs are modest.
• Specialised education models (LearnLM etc.) — worth evaluating as they mature; today still narrower than the general-purpose frontier models.

Build the tutor so you can switch providers in a single config change. Lock-in to one vendor’s API surface is the most common architectural mistake we fix on rescue projects.

When not to build an AI learning platform

Sometimes the right answer is simpler. We push teams off a custom build when:

• Your catalogue is under 20 courses and under 1,000 learners. Teachable, Thinkific or Kajabi will ship in a week.
• You have no pedagogy team. Without instructional designers, AI features will amplify weak content rather than fix it.
• You need it live in under 90 days. Pick a SaaS LMS and invest engineering on the AI modules, not on rebuilding the LMS.
• Your differentiator is content, not software. A great course on a basic LMS beats a basic course on a perfect LMS every time.

FAQ

What to Read Next

Ready to ship your own Scholarly-class platform

Scholarly shows what a modern AI-powered learning platform actually looks like in production: a crisp LMS core, live video that scales to 2,000 students, AI wherever it demonstrably lifts outcomes, and compliance baked into the foundation. The playbook we follow is simple — buy what is commodity, build what is unique, ship AI only where it earns its keep.

If you are sizing a similar build or sketching an AI retrofit onto your existing LMS, the next step is a 30-minute scoping call. We will map your pedagogy, scale and compliance to the right stack, estimate the timeline and budget, and leave you with a clearer picture than a week of internal debate.