Features of a learning management system: the counted list from 38 real platforms
Most lists of learning management system features are guesses dressed as specifications: somebody's memory of a demo, padded with whatever the vendor's marketing page happened to bullet. They are useless for the two jobs people actually need them for — writing requirements, and judging whether the thing in front of you is real.
This one is counted. We went through 38 real LMS platforms across five source families: live SaaS creator platforms (TalentLMS, LearnWorlds, Thinkific, Teachable, Kajabi), open-source and academic systems (Moodle, Canvas, Open edX, OpenOLAT, Chamilo), marketplace scripts with authenticated demo access, enterprise RFPs and feature comparison documents, and practitioner pain threads. A capability was tallied only when a source directly evidenced it shipping — a real screen, a real workflow, a real operational concern.
The counts tell you which features are load-bearing and which are optional, so you can scope a programme instead of cargo-culting a feature grid.
The other thing this list does that a bullet list cannot: for each feature it gives you the difference between the real version and the decorative one. Almost every LMS disappointment is a feature that exists on screen but does not do the work behind it, and every entry below comes with a test you can run in a trial account in about two minutes.
The core eight, ranked
| Feature | Platforms (of 38) | Share |
|---|---|---|
| Lesson and content types | 33 | 87% |
| Course builder with real hierarchy | 32 | 84% |
| Learner progress tracking | 32 | 84% |
| Course catalogue | 31 | 82% |
| Roles and permissions | 31 | 82% |
| Reports and analytics | 31 | 82% |
| Product and tenant model | 30 | 79% |
| Assessments and quizzes | 29 | 76% |
Nothing else cleared that bar, and that is the useful part of the finding. Everything people argue about in procurement — gamification, discussion forums, SCORM, live sessions, an AI tutor — sits below this line, which does not make those features worthless. It makes them branch features, and treating a branch feature as core is the most reliable way to end up with a system that does ten things adequately and none of them well.
1 · Lesson and content types — 33 of 38
Video, text, file and PDF, audio, embedded media, HTML pages, downloadable assets. The most universal capability in the set, and the one most likely to be quietly narrower than it looks.
Decorative version: an "upload" button that accepts anything and renders it as a download link. Real version: each type has its own player or renderer, tracks whether it was actually consumed, and behaves on a phone.
The test: upload a 40-minute video and a 12-page PDF. Watch three minutes, leave, come back. Does it resume where you stopped? A system that cannot tell you how much of a video was watched cannot tell you anything about progress either — it is recording that you opened a page.
Decide early which types you genuinely need. "All of them" is how a six-week build becomes six months, and most programmes run on two.
2 · Course builder with a real hierarchy — 32 of 38
A drag-and-drop tree of modules, sections and lessons — not a flat list of files with an ordering number.
Decorative version: a list of uploads you reorder. Real version: a nested structure where a module can be released on a schedule, a section can be locked behind a prerequisite, and moving a lesson does not orphan anybody's progress.
The test: build a course with two modules, put a lesson in the wrong one, and move it. Then check a learner who had already completed that lesson. If their progress is now wrong, the hierarchy is cosmetic and progress is keyed to position rather than to the lesson itself.
This is the single most common structural failure in a built-from-scratch LMS, and the reason is mundane: a flat list is dramatically easier to build and looks identical until the first reorganisation.
3 · Learner progress tracking — 32 of 38
Lesson completion, percentage progress, a resume point, a completion date.
Decorative version: a progress bar computed in the browser from what the current page knows. Real version: durable records written to the server, keyed to the learner and the lesson, surviving a refresh, a new device and a new session.
The test: complete two lessons, hard-refresh, then sign in on a different browser. If the progress bar resets, nothing was stored — and every report built on top of it is fiction.
This one is worth being blunt about. Progress that lives in component state is the defining defect of prompt-built learning platforms. It demos perfectly, because a demo never involves a second session.
4 · Course catalogue — 31 of 38
Public, private, role-restricted or marketplace, depending on the model you chose.
Decorative version: a grid of every course, visible to everyone. Real version: visibility is a rule — by enrolment, by role, by organisation, by publication state — and drafts are genuinely invisible rather than merely unlinked.
The test: create a draft course, copy its URL, open it signed out or as an unenrolled learner. If you can read it, the catalogue is a filter on the front end, not a permission.
5 · Roles and permissions — 31 of 38
Administrator, instructor and learner as the core; manager, organisation admin, moderator and affiliate are branch roles that come with the models that need them.
Decorative version: a role field that changes which menu items appear. Real version: every request is checked on the server, and hiding the button is a convenience rather than the control.
The test: sign in as a learner and paste in an instructor URL — the course editor, the report screen, another learner's record. Being redirected is fine. Seeing the page is not. Then check the page source, not just the screen, because the most common version of this failure is a server that sends everything and a front end that hides most of it.
6 · Reports and analytics — 31 of 38
Completion rates, at-risk learners, assessment outcomes, activity over time.
Decorative version: counters incremented as things happen and stored alongside the data. Real version: every figure derived at read time from the progress, attempt and enrolment records.
The test: find a number on a dashboard and reproduce it by hand from the underlying list. If it does not match, one of them is lying and you cannot tell which. Then delete an enrolment and check whether the count moves.
Parallel counters are seductive because they are fast and simple, and they drift the first time anything is edited, merged or deleted. Once a report and the records can disagree, the report is worse than having no report, because people act on it.
7 · Product and tenant model — 30 of 38
Single creator, organisation, school, corporate with branches, or marketplace. This is the decision that determines data isolation, and it is the one nobody asks about until it is expensive.
Decorative version: an organisation column on a few tables. Real version: every query
carries the boundary, and one organisation's learners are invisible to another in both directions.
The test: two organisations, data in each, sign in as one and try to open the other's record by its identifier. Then do the reverse — the owning organisation must actually see its own record, or an empty result for everybody is just an empty database rather than working isolation.
That control matters more than it sounds. It is the difference between proving isolation and proving nothing.
8 · Assessments and quizzes — 29 of 38
Even the lightest quiz needs attempt records, scores and feedback — not a pass or fail flag on an enrolment.
Decorative version: a score written onto the enrolment row, overwritten each attempt. Real version: an attempt ledger — every attempt, its answers, its score, when it happened, what feedback was given.
The test: fail a quiz, pass it, then look for the failed attempt. If it is gone, you have a current status dressed as a record, and you can never answer "how many attempts did this take" or "which question does everyone get wrong".
What is deliberately not on the list
Ten families sit below the core, and each of them is a real product decision rather than a feature to tick: live and cohort sessions; school gradebook and weighting; corporate compliance and recertification; community and discussions; course marketplace and ecommerce; SCORM, xAPI, cmi5 and LTI; native and offline mobile; AI authoring and tutoring; content library and migration; and single sign-on.
Each one is right for somebody. None is right for everybody, and the cost of including one you do not need is not just the build time — it is that it drags its own data model in with it. Add marketplace ecommerce and you have acquired instructor payouts, commission, coupons and refunds. Add SCORM and you have acquired a runtime and a packaging format. Add a gradebook and you have acquired weighting rules that will be argued about for a year.
The honest way to use this list is to pick your branches deliberately, in writing, before anyone builds anything — and to be able to say why each one is in.
The requirements list you can hand someone
If you need this as a specification rather than an essay, this is the shape of it. It is written to be checkable, because a requirement nobody can test is a preference.
- Content types: [name the two or three you actually need], each with a real renderer and a resume point.
- Courses are a module/section/lesson hierarchy. Reordering must not affect recorded progress.
- Progress is stored server-side per learner per lesson, survives refresh and a second device, and records a completion timestamp.
- Catalogue visibility is enforced server-side. Drafts are unreachable by direct URL.
- Roles: [list them]. Every restricted route is refused on the server, verified by requesting it directly as the restricted role.
- All reported figures derive from progress, attempt and enrolment records at read time. No stored counters.
- Tenancy model: [single / organisation / school / corporate / marketplace]. Isolation proved in both directions with a control.
- Assessments write an attempt record per attempt — score, answers, timestamp, feedback — and no attempt is overwritten.
- Certificates, if issued, reference the completion record that earned them and can be verified after the fact.
- A production build is produced and run before handover, not just a development server.
That last one is not a feature. It is on the list because it is the requirement most often assumed and least often met.
Why AI-built learning platforms miss these
Ask a coding agent for an LMS and it will give you a catalogue, a course page, a lesson list, a progress bar and a dashboard, and they will look right. What it will not do unprompted is the part that makes them real, because nothing in the request said to and the version it has seen ten thousand times in training does not have it.
The failure is consistent: content as a flat file list instead of a hierarchy, progress that vanishes on refresh, quiz scores that are never tied to an attempt record, and reports that are parallel counters rather than derived figures. Four defects, and every one of them is invisible in a demo.
We tested this rather than assumed it. Three complete learning platforms were built from a single specification by three different coding models, and the audit was aimed at the things an LMS cannot get wrong: whether one learner can reach another's record, whether a completion is earned rather than asserted, and whether a certificate means anything. All three worked as applications. One would not compile for production — three small errors that never appear in development, which its own tests reported as passing. One built every access rule correctly on top of a session token a visitor could have forged, so the correct rules were decoration. One shipped a catalogue that was 83% leftover test data. The strongest of the three kept every organisation's learners invisible to every other in both directions and refused even its own academy administrator the screens that belonged to a training manager.
The full ranking, with the live systems you can sign into, is published as a build-off board.
The difference between those outcomes was not model capability. It was how much of the list above the specification made non-optional.
If your problem is recording training rather than delivering it, training tracking in Excel covers the matrix and where it breaks. Free learning management system covers where the free tiers stop, and open source LMS has the honest cost of self-hosting.
If you are pointing a coding agent at this, the Learning Management planner is the specification we hand ours — this inventory, the branch families as explicit choices, and handover gates that require the proof rather than the claim.