The course nobody finishes

How to build an elearning platform that people finish

How to build an elearning platform that people finish, in one sentence: design the product around completion rather than enrolment. That means three decisions in order: draw the build or buy line so custom engineering only goes where your differentiator lives, fund the social mechanics (cohorts, deadlines, visible progress) that hold learners in a course, and keep any AI tutor under human review for anything graded. Feature parity with an incumbent LMS is easy to buy. A completion rate that survives week three is not.

Most platform briefs arrive as feature lists. Course builder, quiz engine, certificates, reporting. Each of those is table stakes, and none of them predicts whether a learner reaches the last module. The number that predicts renewal, reputation and every downstream business claim is the share of starters who finish, and on most projects it is nobody’s job.

The gap between those two figures is not video quality. It is structure: whether anyone else is in the course with you, whether anything happens when you stop, and whether the platform notices you have stalled before you quietly go.

Why does completion decide the business case?

Because everything the platform is sold on is priced off finishers. Certificates, skills data, compliance evidence, promotion decisions and renewal conversations all trigger on completion. None of them trigger on an enrolment. A platform reporting fast enrolment growth and single-digit completion is reporting one real number and one vanity number.

The budgets are real. The average company spends about $1,420 per employee on training,⁴ which makes drop-off a line item rather than a design complaint. Resist the temptation to build the case on the widely quoted figure that every dollar of online training can return up to 30 dollars in productivity: that is cited as a ceiling, not a typical result,⁵ and putting it in a board pack is a fast way to lose the room. The defensible version is narrower. Measurement correlates with return, and measurement starts with completion.

There is a structural reason vendors under-invest here. A platform priced per seat earns the same whether learners finish or not, so drop-off becomes somebody else’s problem and the roadmap fills with authoring features that demo well. Enterprise buyers can correct for this with one question: ask for completion rates by cohort across existing customers before signing, not at the first renewal. Vendors who track it will show you. Vendors who do not will show you something else.

Those bars come from different compilations and different course populations, so read them as direction rather than benchmark. A standard self-paced course sits near 12%, inside the 5% to 15% band typically reported for online courses.¹ Gamified courses are reported at about 90% and courses carrying a completion incentive at about 85%,⁶ while personalised learning paths are linked to roughly 35 points of additional completion,⁶ which puts them near 47% against that self-paced baseline. Selection effects are doing some of the work, because the course that gets a gamification budget is usually the course somebody already cared about. The direction still holds. Structure moves completion further than content does.

Should you build a custom LMS or configure an existing one?

Configure an existing LMS unless the learning experience itself is your differentiator. Custom LMS development earns its cost when what you are selling is the pedagogy (adaptive sequencing, simulation, assessment integrity, a domain-specific practice environment) or when the platform is a wedge into a product you already own. It is not justified by dissatisfaction with a vendor’s reporting screen.

The market itself makes the argument. Grand View Research puts the global LMS market at $28.6 billion in 2025 and roughly $34.1 billion in 2026, with estimates across research firms running as high as $31.4 billion for 2025 and $37 billion for 2026.⁷ A market that size has mature commodity layers. Enrolment, catalogue, roles, notifications, certificates and standard reporting have been solved several times over, and rebuilding them buys you nothing a buyer can see.

A middle path usually beats both extremes: buy the commodity layer, build the differentiator against its APIs, and keep the learner record in a store you control. That keeps engineering effort pointed at the part a competitor cannot buy from the same vendor next quarter.

How to build an elearning platform: the six subsystems

Six subsystems, and the build order matters more than the stack choice.

1. Identity and enrolment. Single sign-on, roles, cohorts, seat management. Model cohorts properly at the start, because every retention feature later depends on a group being a first-class object rather than a report filter.
2. Content and authoring. Versioned, structured units with previewable drafts. Content operations break before the player does.
3. Delivery. Video transcoded once into adaptive bitrate renditions, served from a CDN behind signed URLs.
4. Assessment. Item banks, attempt limits, and an integrity position decided early, since proctoring changes both the architecture and the privacy notice.
5. The learning record. A durable store of what each learner did, kept separate from the course player.
6. Analytics. Drop-off by module, stall detection, cohort comparison. Written off the request path.

Video is where budgets go missing. The pattern that holds at scale is to transcode once, store cheaply, cache aggressively and never stream from your origin. Use a managed video pipeline until traffic genuinely justifies running your own, cap default resolutions rather than serving the highest the device will accept, and make the audio track usable alone. As for language, Node and Python both carry this workload comfortably; pick the one your team can operate at 3am. Scalability is decided by the media pipeline and the caching strategy, not by the framework.

SCORM or xAPI?

They are not interchangeable, and the choice is close to irreversible. SCORM packages course content and reports completion and scores back to a single LMS. xAPI (Tin Can) records learning experiences across systems, including mobile, simulations and on-the-job activity, and writes them to a Learning Record Store. A platform built only for SCORM can satisfy a procurement checklist today and block a mobile-first or blended roadmap tomorrow, because its tracking model assumes one system and one session. If anything on the roadmap happens outside the course player, specify xAPI and a Learning Record Store from the first sprint.

Accessibility and regulated content

WCAG AA is the working standard and the one procurement will ask you to evidence: captions and transcripts on every video, keyboard-operable players, sufficient contrast, and assessments that do not depend on drag and drop alone. Retrofitting captions across a back catalogue costs several times what producing them alongside the video would have. Where the platform carries health data or delivers clinical training, the learner record inherits the same obligations as any other system holding it, and the layered control model set out in our note on HIPAA compliant app development applies to a learning platform as much as to a patient app.

Which features actually stop learners dropping off?

The ones that add other people and deadlines. Content polish, production values and player performance all matter up to a baseline, and then they stop paying. Social structure keeps paying.

Content quality has a ceiling most teams reach faster than they expect. Social accountability does not.

1. Cohorts with dates. A start date, a finish date and other people moving at the same pace. This is the lever that most reliably separates a course finished by a tenth of its intake from one finished by most of it.
2. Consequences for finishing. The incentive-linked completion figures above are compiled and generous, but the mechanism is not in doubt: something has to happen at the end that the learner wants.
3. Personalised paths. Skipping what someone already knows respects their time and shortens the distance to the certificate.
4. Stall-triggered nudges. Fire on behaviour (no activity since a specific module), not on a weekly schedule. Scheduled reminders train people to filter you.
5. Gamification, with the caveat. Points and streaks work when they mark progress toward something real. They decorate a course that has no stakes.

Mobile deserves its own note, because it is a different completion curve rather than a smaller screen. Mobile learning was forecast to account for 40% of all e-learning activity globally by 2025.⁸ A desktop lesson ported to a phone inherits none of the behaviour that makes mobile work. Chunk into five to ten minute units, keep a resumable position that survives an app being killed, and let someone finish something whole on a single commute.

Are AI tutors worth building, or are they a gimmick?

Worth building, with a boundary. The learning evidence is real: a randomised controlled trial published in Scientific Reports in 2025 found the AI tutor group showed significantly greater learning gains than in-class active learning.⁹ The reliability evidence is also real, and it points at a specific architecture rather than a free-standing bot.

Read those two findings together and the design falls out. The configuration that matched human quality was AI assisting a human, not AI operating alone. So for anything graded, credentialed or safety-relevant, the AI drafts and a person owns the output: hint generation against instructor-reviewed hint banks, misconception detection routed to a human, feedback drafted for a marker to approve. For low-stakes practice, unblocking and revision questions, autonomous is fine, and the cost per learner is the only reason it is possible at all.

The engineering follows the same split. Ground answers in your own course content rather than a general model’s world knowledge, write every exchange to the learner record, and sample transcripts for review the way that study did. An AI tutor with no audit trail cannot be defended the first time a learner disputes a grade. If you are weighing where this sits in a wider roadmap, it is the same scoping question we work through when we design AI systems that stay under human review.

What does an MVP look like, and how do you prove ROI?

Scope the first release to one course, one cohort and one number. Everything else is a later release pretending to be a requirement.

1. Pick a course with a known audience and a known outcome, so completion means something to somebody.
2. Ship the smallest complete loop: enrol, learn, assess, record, certify.
3. Instrument completion on day one. Per-module drop-off, time to first stall, resume rate, cost per completion.
4. Run the first cohort with real dates and a human facilitator before you automate anything.
5. Point the AI tutor at the module with the worst drop-off, not the one that demos best.
6. Only then invest in authoring depth, catalogue and admin tooling.

Timelines vary too much by scope for a number here to be honest, but the shape is predictable: the loop above is a matter of weeks, and the content operations behind it are the part that runs long. Teams that reverse the order build a beautiful catalogue for courses nobody finished.

ROI has two tiers. Tier one is platform-side and available immediately: completion by cohort, time to competence, cost per completion (not cost per seat) and support load per hundred learners. Tier two is business-side and needs a baseline you capture before launch, not after: error rates, ramp time for new hires, certification pass rates, retention in the roles you trained. Skip the baseline and you will be arguing from anecdote for two years. If the platform is still a decision rather than a plan, the cheapest hour you will spend is the one before the architecture hardens, so tell us what you are trying to get people to finish.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.