LMS development: the complete guide to building a learning platform

Disclosure: LMS Advisor is built by the All-in-One LMS team. Where it appears on this page it is marked as our product and described from its public documentation, limitations included.

LMS development is the work of designing, building and maintaining learning management system software. It follows one of three routes: configuring an existing platform, extending an open-source or self-hosted platform with custom code, or building a new platform from scratch. In our experience, many projects described as custom LMS development are really the second route, and picking the right route matters more than any choice of technology.

This guide is for founders, CTOs, product owners and heads of L&D or training who are considering having a learning platform built or heavily customised, and who want to understand the work before they talk to a development team. It is written by engineers who build and extend these platforms, it prescribes no stack, and it says plainly where building is the wrong choice.

It covers the configure, extend or build decision, the data model, the content standards (SCORM, xAPI, cmi5 and LTI 1.3), the architecture choices that are expensive to reverse, and what you, the client, must provide at every phase.

What LMS development means today: three routes

The terms LMS development, learning management system development and LMS software development cover very different amounts of engineering: a week of configuration, a few months of plugin work or many months of product development. Before anyone estimates anything, place the project on one of three routes.

The routes differ most in who carries the long-term cost. On the first, the vendor maintains everything and you live with its limits. On the second, the platform's maintainers look after the core and you look after your additions. On the third, every line is yours, password reset included.

How to tell which route your project is

Four questions settle it in most cases:

1. Is the platform your product, or a tool you use? If you sell access to the platform itself, control of the code and roadmap is worth paying for. If it supports your own staff, customers or members, it rarely is.
2. Where are the gaps? A missing report, integration or approval step is a gap at the edge, and a plugin can fill it. A different idea of what a course, an enrolment or a client organisation is sits in the core, and you will work around it for years.
3. Who will run it in three years? A build needs a team that stays. An extended platform needs someone to apply upgrades and retest your additions. A configured SaaS product needs an administrator.
4. What must you own, and what do licences cost at your volume? Investors, clients or regulators sometimes require that you hold the code or host the data yourself. Per-user pricing that is reasonable for a few hundred learners can cost more than owning the software at tens of thousands. Both point to routes two and three.

Once these answers are written down, many projects that start as "custom LMS development" turn out to be route two: a proven core, plus the workflows, integrations and screens that make the organisation different. That is a good outcome: the budget goes on what is unique to you.

Before you build: check what an existing platform already covers

A build from scratch pays for sign-in, a course catalogue, a quiz engine, a content player, certificates, notifications and reports before it reaches the first feature that is unique to you. If an existing platform already covers most of your must-have requirements, extending it is usually cheaper and safer than a new build, because that common ground has already been written, run in production and patched by someone else.

So the first output of any project should be a fit check: your must-haves scored against two or three candidate bases. Four kinds of base come up most often.

LMS Advisor (our product). LMS Advisor is the "buy a ready-made LMS and extend it through its API" option here: an enterprise LMS that is the same product in the vendor's cloud or on your own server. Its product page lists SCORM 1.2 and 2004, xAPI with a built-in learning record store, cmi5, SAML single sign-on, SCIM provisioning, native proctored exams, verifiable certificates, and a REST API with signed webhooks.

The same page lists its limits. Pricing is quote-based. It is not a course-selling storefront: there is no built-in checkout, coupons or subscriptions, and selling goes through a WooCommerce plugin. Other platforms can launch it through LTI 1.3, but it does not launch external tools. Its other pages state that it holds no SOC 2, ISO 27001 or HIPAA certification and describe its tenants feature as early. If you plan to change the product itself, ask what the self-hosted licence lets you modify. If a ready-made base is on your list, see what LMS Advisor includes.

Moodle 5.3, released in October 2026, is a long-term support version with security fixes scheduled until October 2029. Open edX's current named release is Verawood, with the next, Willow, scheduled for December 2026. For LifterLMS, our sister site LifterLMS Expert goes into the detail.

What the licences mean for your custom code

Under Moodle's GPL you may modify the software, and if you distribute a modified version you must pass the same rights on and make the source available. Open edX's AGPL adds a network clause: a modified version must offer the people who use it over a network the chance to receive its source code. WordPress states that derivatives of WordPress code inherit the GPL. If your plan depends on keeping modifications private or reselling the software itself, have a lawyer review the licence first.

Building from scratch is still the right call when the platform is the product you sell, when learning must be embedded inside another application and you need an engine with no interface of its own, or when contract or regulatory terms rule out the licences or hosting models above. If none of these is true, extend.

The core modules of an LMS and what each one involves

A feature list makes an LMS look like a set of screens. From the build side it is a set of modules that share one data model. Whether you build a learning management system or extend one, walk through this table with your team.

The data model that everything depends on

Many late surprises in LMS software development trace back to the data model, not to a screen. The entities are few: user, organisation, course, course version, activity, enrolment, attempt, completion and certificate. The rules between them are where projects go wrong.

• Keep enrolment, progress and completion separate. Enrolment is the right to take a course. Progress is what has happened so far. Completion is the result an auditor reads. One merged status field works until a course is re-assigned for annual renewal.
• Treat completions and certificates as records. Store what was completed, which version, when, with what score and under which rule. Otherwise editing a course quietly rewrites last year's compliance report.
• Give every row an owner. Attach users, courses and results to an organisation from the start, even if you launch with one. Adding that key later means touching every query.
• Decide what "delete" means. When a person leaves, do you deactivate the account and keep the training record, anonymise it or erase it?

Content standards and interoperability: SCORM, xAPI, cmi5 and LTI 1.3

If your courses come from authoring tools or third-party libraries, the platform has to speak their standards. Each one is a piece of software to implement or adopt, not a tick on a feature list.

Decide whether to write, adopt or embed. Moodle, for example, ships with a SCORM activity, which is a strong argument for route two. On a scratch build, SCORM 2004 sequencing, an LRS and cmi5 are each a project of their own, so decide for each whether you write it, reuse an open-source component or license a commercial engine.

The specification is the smaller half. The larger half is behaviour at the edges: what is saved when a learner closes the tab mid-lesson, what happens when the session expires during a long video, and how a retake affects a stored completion. Packages from different authoring tools also behave differently, so testing with one sample file proves little.

Choose the LTI role deliberately. Launching other vendors' tools and being launched by a customer's LMS are separate pieces of work. Many projects need only one. Our SCORM vs xAPI vs cmi5 comparison goes deeper into which standard suits which content.

Architecture and integration decisions that are expensive to change

None of these decisions has one right answer. Each is a trade-off to make on purpose during discovery and to write down with the reason, because reversing it after launch is costly.

An LMS does a lot of work that no user should wait for: sending reminders, generating certificates, unpacking packages, importing users and building large reports. That work belongs in a queue with retries that administrators can see, because a reminder that silently never sent becomes a compliance problem a month later.

Load is also uneven. It peaks on a compliance deadline, at the start of a timed exam and when a new cohort opens, so design and load test for those moments, not for the daily average.

Integrations almost every project needs

• Single sign-on. SAML 2.0, an OASIS standard, is what corporate identity providers commonly expect. OpenID Connect, an identity layer on top of OAuth 2.0, suits newer identity providers and mobile apps. Decide whether accounts are created at first sign-in, how attributes map to roles and what happens on logout. Our guide to SAML and OIDC single sign-on for an LMS covers the choice.
• HRIS or student-system sync. Sign-in alone does not create or remove accounts ahead of time. Where the identity provider supports it, SCIM (RFC 7644) is a standard HTTP-based protocol for that. Otherwise it is a scheduled API sync or a file transfer. The mapping is the hard part: department, manager, location, leavers and returners.
• Payments. Use the provider's hosted checkout so that card numbers never touch your servers. PCI DSS applies to entities that store, process or transmit cardholder data, so the less of that your platform does, the better. The effort goes into what follows payment: enrolment, invoices, tax, refunds and failed renewals.
• Video conferencing. Scheduling live sessions in Zoom, Microsoft Teams or Google Meet from a course, and bringing attendance and recordings back.
• CRM. For customer and partner training: accounts and entitlements flowing in, completions and certifications flowing back.
• BI and data warehouse. An export, an API or a read replica for the tools leaders already use. Agree what counts as active, complete and overdue before building the feed.

For every integration, write down which system holds the truth, what triggers the exchange, which direction data moves and what happens when the other system is unavailable.

Security, privacy and accessibility requirements that shape the build

All three are far cheaper as requirements at the start than as findings from a penetration test, a legal review or an accessibility audit at the end.

Security

The current OWASP Top 10, the 2025 edition, puts Broken Access Control first. An LMS is mostly access control: a learner sees their own results, a manager a team, a client administrator one organisation. Each rule has to be enforced on the server for every record and tested for each role through the screens, the API, imports and exports.

As a requirement list, use the OWASP Application Security Verification Standard (version 5.0.0, May 2025), a set of security requirements for designing, developing and testing web applications and services. Then add the points specific to learning platforms:

• Uploaded course packages contain HTML and JavaScript that will run in learners' browsers, so treat uploading as a privileged action and log it.
• Correct answers and exam timers stay on the server until the attempt is submitted.
• Certificate verification links use identifiers that cannot be guessed.
• Role changes, grade changes and sign-in as another user go to an audit log.
• Third-party plugins and libraries are reviewed and kept current. Software Supply Chain Failures is third on the same list.

Privacy: GDPR basics for learner data

An LMS holds names, email addresses, job details, assessment results and, with proctoring, images. If you train people in the EU, the GDPR can apply even when your organisation is established elsewhere, because Article 3 covers offering goods or services to people in the Union. These parts become build requirements:

• Article 5: personal data is limited to what is necessary for the purpose and kept in identifiable form no longer than necessary. In practice: fewer profile fields, and a retention setting for each type of data.
• Article 25: data protection by design and by default.
• Articles 15, 17 and 20: rights of access, erasure and portability, the last in a structured, commonly used and machine-readable format. The platform needs an export and an erase or anonymise function for each person.
• Article 28: where a development partner or host processes learner data on your behalf, a contract must govern that processing.
• Article 32: security appropriate to the risk, including as appropriate encryption and the ability to restore access to data after an incident. That means backups whose restore has been tested.
• Article 33: a breach is notified to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to people.

Erasure requests and the need to keep training records can pull in opposite directions, so settle the rule for each category of data with your legal adviser. Other countries have their own laws, and this is not legal advice.

Accessibility

WCAG 2.2 is a W3C Recommendation with three conformance levels: A, AA and AAA. Level AA is what the contracts and policies we see usually ask for. Version 2.2 added criteria that touch LMS screens directly:

• 2.5.7 Dragging Movements (AA): drag-and-drop question types and course builders need an alternative without dragging.
• 2.5.8 Target Size (Minimum) (AA): player controls and quiz options need enough size or spacing.
• 3.3.8 Accessible Authentication (Minimum) (AA): sign-in must not require a cognitive test, such as remembering a password, unless an alternative or help is offered.

An accessible platform does not make content accessible. Course packages, videos and documents need their own checks.

The LMS development process, phase by phase

If you are working out how to build an LMS, the LMS development process has the same phases on every route. Only their size changes. Durations are indicative planning assumptions for a new build, not commitments. They add up to the 12 to 32 weeks in our LMS cost calculator (October 2026).

Scoping the MVP

A useful test for the first release, the minimum viable product (MVP): one real group of learners can sign in the way they will in production, be enrolled, finish one real course and receive whatever proves it, and one real manager can pull the report they need. Anything off that path can wait for a later release. Gamification, social features, AI features, native mobile apps and a report builder usually do.

QA covers content, not only code

Build a small matrix: each authoring tool you use, each standard, each supported browser and at least one phone. For every cell, check that the package launches, records completion and score, resumes where the learner stopped and copes when the window is closed without warning. It is tedious, and it catches defects that learners would otherwise report in week one.

Migration and launch

If you are replacing a platform, the hard data is history: completions, certificates with their original dates and assessment results. Passwords usually cannot be moved unless both systems store them in a compatible way, so plan for single sign-on or a reset at first login. In-progress state inside packaged content rarely transfers, so decide whether learners who are part-way through restart or finish on the old system. Rehearse the migration at least twice and reconcile the numbers each time.

Maintenance is part of the plan

On an open-source base, upgrades recur: Moodle's schedule shows a major release about every six months, and Open edX publishes named releases at a similar pace. Custom plugins must be retested against each one you adopt. A custom build has no upstream to follow, but its frameworks, libraries and servers still need updating.

The team, and how to evaluate an LMS development company

A new build typically involves a solution architect or business analyst, a UX and UI designer, back-end and front-end engineers, a QA engineer, someone responsible for infrastructure and deployment, and a project manager. On smaller extension projects, two or three people often cover these roles. At least one engineer should have implemented the content standards before.

Your side needs people too: a product owner who can decide, the person who administers training today, someone from IT who owns identity and security, and whoever owns the data in the HR or student system. Projects without a client-side product owner tend to drift.

What to ask

• Which route would you recommend for us, and what would make you advise against a build?
• Which platforms have you extended, and do you write plugins or change core code?
• How do you implement and test SCORM, xAPI, cmi5 and LTI, and with which authoring tools?
• How do you model organisations and permissions, and how are access rules tested?
• Who owns the code, where does the repository live, and which licences apply to the components you use?
• How do you estimate, and how are changes of scope priced?
• What does maintenance include, and what are the response times?

What to ask to see

• A discovery or requirements document from an earlier project, with client details removed.
• A live demonstration in which they sign in as a learner, a manager and an administrator.
• How their code is organised and tested, and the pipeline that deploys it.
• A test plan with a content package matrix, a migration reconciliation report, and evidence of security and accessibility testing.
• People you can call who run a platform they built.

Be cautious of a fixed price offered before discovery, of a proposal that asks nothing about your data, and of "SCORM compliant" stated without a test.

Cost and timeline: what drives them, and the mistakes that inflate both

The route is usually the largest driver. After that, cost and duration follow the number of roles and organisations, the number and quality of integrations, the depth of standards support, assessment and proctoring, reporting, the volume and cleanliness of data to migrate, security and accessibility requirements, mobile apps and how fixed the deadline is.

These are indicative ranges from our LMS cost calculator, October 2026. They are base planning ranges, not quotes: the calculator adds to them for features and integrations and adjusts for platform, learner numbers, complexity and urgency.

The gap between the two rows is the financial case for the fit check. Our LMS development cost guide breaks the numbers down, and the LMS cost calculator gives a range for your own mix of features in a few minutes.

Common LMS development mistakes

• Building what a platform already does. Skipping the fit check and paying to rewrite a catalogue and a quiz engine.
• Starting from screens. Designing pages before the roles, the organisation structure and the completion rules are agreed.
• One line for "SCORM support". Estimating standards as a single item and testing with a single sample package.
• Leaving identity to the end. Single sign-on and HR sync depend on other teams, and they are often where the calendar slips.
• No product owner. Decisions wait for a steering meeting while the team builds its best guess.
• Reports as an afterthought. The data the report needs was never stored.

How we can help

We work on all three routes: fit checks and route decisions, plugins and integrations on Moodle, Open edX and WordPress LMS platforms, and custom platforms where a build is justified. If you want a second opinion on which route your project is, or an estimate based on written requirements, see our LMS development services or talk to an LMS engineer.