Custom LMS development, and when not to build
Custom LMS development means building a learning platform around your own processes, by extending an existing LMS or starting from scratch. This guide covers build versus buy, cost drivers, process, ownership and migration.
Key takeaways
- "Custom" covers three routes: configuring an off-the-shelf LMS, customizing a platform you receive the source code for, and building from scratch.
- Buy or configure unless your process is the product, you need integrations nobody ships, or licensing and data rules exclude the products that would otherwise fit.
- Name the standards you need by version in the requirements: SCORM 1.2 and 2004, xAPI, cmi5, LTI 1.3, SAML 2.0, SCIM 2.0, WCAG 2.2 AA and an OWASP ASVS level.
- Cost follows the route, the roles, the integrations, the standards, mobile apps and migration, which is why published price ranges disagree so widely.
- Put code ownership, third-party licenses, hosting accounts and learner data export in the contract before work starts.
- We sell an off-the-shelf LMS (LMS Advisor), customization of it and builds from scratch, which is why this guide can say when not to build.
Custom LMS development is the design and build of a learning management system (LMS) around one organization's processes, integrations and data rules, by extending an existing platform or writing a new one from scratch. In our experience, teams that ask for it often need far less custom code than they expect. The requirement that feels unique is often a setting in a product that already exists, and the part that really is unique tends to be one workflow or one integration.
A disclosure first. We build LMS Advisor, an off-the-shelf LMS. We also sell custom development on top of that platform, and builds from scratch. Selling all three lets us say which one fits, including when the answer is not to build. Read on with that in mind.
What custom LMS development really means
In practice, "custom LMS development" is used for three different projects: configuring an off-the-shelf LMS, customizing a platform you get the source code for, and building a new system from scratch. Only the last two involve new code. Quotes for the three cannot be compared with each other, so ask which one a vendor is pricing before you read the proposal.
| What to compare | Configure an off-the-shelf LMS | Customize a platform with source code | Build from scratch |
|---|---|---|---|
| Working on day one | Everything the product ships | Everything the base ships, plus your additions as they are built | Nothing until it is built |
| What you own | Your content and data. The software is licensed or rented | Your content and data. You hold the source code under the license terms in your contract | The code written for you, your content and your data. Third-party components keep their own licenses |
| Time to first release | Shortest | In between, because only the differences are built | Longest |
| Upkeep after launch | The vendor maintains the software. You maintain content and users | Shared, on terms the contract should spell out: who updates the base and who looks after the custom layer | All of it is yours, or your developer's under a paid agreement |
| Main risk | The product cannot do the one thing you need | Custom work that fights the base and makes upgrades hard | Paying to rebuild standard features, such as password resets and enrollment emails, and a scope that keeps growing |
| Best fit | Standard onboarding, compliance and product training | A mostly standard LMS plus a few things nobody ships | The learning platform is your product, or nothing close to it exists |
The middle route only protects you when the contract gives you the source code.
Build versus buy: when a custom LMS is justified
A custom LMS is usually justified when your process is the product, you need integrations no vendor ships, or data and licensing rules exclude the products that would otherwise fit. Otherwise, assume you should buy and make the custom route earn its place. A finished product has already paid for its mistakes. A new build has not made them yet.
Signs you should buy or configure
- Your needs are the common ones: onboarding, compliance courses, product training, certificates and reports by manager.
- You need to be live soon, and nobody on your side can own a software project.
- Your "custom" list is mostly look and feel, wording, roles and report filters.
- Your audience is a known size, so a per-user fee is predictable.
If that sounds like you, compare LMS software first. If you mainly sell video courses to individuals, a creator platform is likely to serve you better than a custom LMS project, and a small course site is usually fine on a WordPress LMS plugin.
Signs custom is justified
- Your process is the product. You sell training, assessment or certification, and the way you deliver it is what people pay for.
- You need integrations nobody ships. An in-house ERP, a licensing board's system, a legacy records database.
- Data residency or licensing rules exclude a vendor's cloud. The system must run on your own servers, in a named country, or inside a network with no outside access. Check self-hosted off-the-shelf products first.
- Per-seat fees grow with an audience you cannot cap. Customers, members, franchisees or the public.
- You run an exam or credential workflow that the products you tested cannot handle. Eligibility checks, review of proctoring evidence, appeals, retake rules and renewal cycles that follow your own rulebook.
Do not build if
- The main reason is that you dislike your current vendor's interface. A different product usually costs less than a new platform.
- You cannot name the person who will own the product after launch, or the budget that will maintain it.
- The requirement list still reads "everything our current LMS does, but better".
- You have not tried the workflow in an off-the-shelf product. Run a pilot, then build only what the pilot proves is missing.
What a custom LMS must include that buyers forget
Beyond courses and quizzes, a custom LMS specification should cover single sign-on and provisioning, named content standards, exam integrity, verifiable certificates with audit trails, accessibility and security targets, mobile apps and AI data handling. These items tend to go missing from the requirements and come back later as change requests.
Identity: single sign-on and provisioning
SAML 2.0 single sign-on (SSO) lets people log in with the company account they already have. SCIM (System for Cross-domain Identity Management) is the standard an identity provider uses to create, update and deactivate accounts automatically. SSO without SCIM can leave accounts active in the LMS for people who have left, until someone removes them by hand. Ask for both, and list the attributes that must sync (department, manager, location), because reports by team depend on them. For a finished version, see SAML SSO and SCIM provisioning in LMS Advisor.
Content standards, named by version
"Supports eLearning standards" is not a requirement. Each of these is a separate piece of engineering:
- SCORM 1.2 and SCORM 2004. The package formats that authoring tools export. If you own courses exported from an authoring tool, you probably need at least SCORM 1.2.
- xAPI with a Learning Record Store (LRS). xAPI records learning activity as statements, and the LRS is the server that receives and stores them. It matters when learning happens outside a browser course: simulators, apps, work on the job.
- cmi5. It uses xAPI as its data layer and adds the launch, session and reporting rules an LMS needs. It was created as an alternative to SCORM, with the intent of replacing it.
- LTI 1.3. Learning Tools Interoperability connects an LMS to outside tools, or lets your courses appear inside someone else's LMS. 1EdTech, which maintains it, lists LTI 1.3 as the current version. Decide which side you are: the platform that launches tools, or the tool being launched.
To choose, list the content you already own and the systems you must connect to. ADL, which created SCORM, now recommends xAPI and cmi5 for new eLearning acquisitions while accepting that SCORM is still in wide use. A practical reading: SCORM for the library you have, cmi5 or xAPI for what you build next. Do not ask for all four "to be safe". Our comparison of SCORM, xAPI and cmi5 goes deeper.
Assessments and exam integrity
Build guides often skip this item, and it is hard to add late. If a result carries weight (a license, a certification, a hiring decision), the specification needs a question bank with pools and randomization, time limits enforced by the server, one active session per candidate and a record of every attempt. Proctoring adds identity capture, webcam and screen evidence, a log of violations and a review screen. Software flags. A person decides. Write down how long evidence is kept and what candidates consent to. See how native proctored exams work in our platform.
Certificates, reporting and audit trails
A certificate is only useful if a third party can check it, so plan a public verification page, plus expiry and renewal rules if your credentials lapse. For reporting, start from the exports an auditor or regulator will ask for and work backward. Add an audit log of administrator actions, so you can show who changed a grade or reissued a certificate, along with retention settings and a way to handle privacy requests. Look at certificates and compliance records in a finished product before you specify your own.
Accessibility and security, written as standards
"Accessible" and "secure" mean nothing in a contract until they name a standard. For accessibility a common target is level AA of WCAG 2.2, the Web Content Accessibility Guidelines published by the W3C. The W3C's WCAG overview encourages using the latest version and notes that content meeting 2.2 also meets 2.1, so there is little reason to write the older version into a new contract.
For security, OWASP's Application Security Verification Standard (ASVS) defines three verification levels. OWASP describes this exact use: the buyer of custom development requires a stated ASVS level and asks the seller to prove the software meets it. Name both standards at the start, with who tests them and when, so they are designed in and priced. Added after launch, either one means rework.
Mobile apps and app store rules
Decide early between responsive web, an installable web app and native iOS and Android apps, since each one adds scope. If you want an app under your own brand that is built from a vendor's existing app, Apple has a rule for that. App Review Guideline 4.2.6 says apps created from a commercialized template "will be rejected unless they are submitted directly by the provider of the app's content". Your organization needs its own Apple developer account, and usually a Google one, and the vendor publishes through them. Store review is outside any vendor's control, so nobody can promise you an approval date.
AI features and data handling
If the platform will generate course content, grade work or answer learner questions, the specification should say which model provider processes the text, what learner data is sent to it, whether an administrator can switch AI off, and whether a person approves AI output before learners see it.
What drives the cost of a custom LMS
The cost of a custom LMS is driven by the route you choose, the number of roles and integrations, the content standards, mobile apps, migration, compliance targets, peak load and team structure. We publish no prices for development work, because the price follows the scope.
| Cost driver | Why it moves the price | How to keep it down |
|---|---|---|
| Route | A build from scratch pays for standard features before it reaches the unique ones | Start from a platform when it already covers most of your list |
| Scope and number of roles | Each role (learner, instructor, manager, administrator, reviewer) needs its own screens, permissions and tests | Launch with the roles that must exist on day one |
| Integrations | Each one is a small project that depends on someone else's API, test environment and schedule | Use standards such as SAML, SCIM, LTI and webhooks before custom connectors |
| Content standards | A SCORM player, an LRS, cmi5 launch and LTI are each specialist work with their own testing | Name only the ones your content and partners require |
| Mobile apps | Two app stores, offline rules and release cycles on top of the web build | Begin with responsive web, or a branded version of an existing app |
| Migration | The effort usually follows the quality of the old data more than its volume | Decide early how much history must move, and archive the rest |
| Compliance and accessibility | A WCAG target, a security verification level and audit trails add design, testing and documentation | Name them before design starts so nothing is redone |
| Hosting and concurrency | A thousand people in one exam hour is a different system from the same thousand spread over a month | Give real peak numbers, and load test the busiest workflow |
| Team location and structure | Rates differ by country and by whether the team is staff or subcontracted | Compare quotes on scope and deliverables, not on the hourly rate |
Why published price ranges disagree
Search for the cost of a custom LMS and you will find figures that sit very far apart. The authors are describing different projects: a first release with one role and no integrations, or an enterprise platform with mobile apps and a migration, on different routes, built by teams in different countries. A range tells you little until you know the route, the scope and the team behind it.
The costs after launch
A custom LMS has no subscription, which is not the same as having no running cost. Plan a yearly budget for:
- Hosting. Servers, storage, video delivery, backups and monitoring.
- Maintenance. Bug fixes, browser changes and upgrades to the libraries the code depends on.
- Security updates. Patches, periodic testing and a response when someone reports a vulnerability.
- New features. The backlog that appears in the first month of real use.
- Third-party services. Video conferencing, email and SMS delivery, AI model usage and app store accounts.
With a hosted off-the-shelf product, most of these sit inside the fee, so compare the two on that basis. Our guide to LMS total cost of ownership lays out the full comparison.
How long a custom LMS takes
A custom LMS project can take weeks when it is a focused add-on to an existing platform, and usually takes months when it is a full custom platform. A project that starts from a working platform is usually faster than one that starts from an empty repository.
Any date offered before discovery is a guess, which is why milestones belong in the quote. The usual delays have little to do with coding:
- Waiting for access to a third-party system or its test environment.
- Security and legal reviews that start after the build instead of alongside it.
- Course content that is not ready when the platform is.
- Decisions that need a committee. Name one person who can say yes.
The process, phase by phase, and what you decide in each
- Discovery and requirements. Interviews with the people who run training, exports from the current system, and a written list of roles, workflows, integrations and standards. You decide who the product owner is and what must exist on day one.
- Options report. A good partner comes back with the three routes compared for your case, including "buy this product and configure it". You decide the route.
- Data model and prototype. The core records (users, organizations, courses, enrollments, attempts, certificates) and clickable screens for the riskiest workflow. You decide whether the model matches how you work. Changing it later is usually the most expensive change there is.
- Build in milestones. Each milestone ends with working software on a staging site, not a status report. You decide whether to accept it against written acceptance criteria.
- Migration. Test imports and count checks, covered below. You decide how much history moves and when the old system freezes.
- Launch. A pilot group first, then everyone. You decide go or no-go, with a rollback plan agreed in advance.
- Handover. The code repository, documentation, administrator training and a maintenance agreement. You decide who maintains it: the builder, your own team or another vendor.
Who owns the code, the licenses and the learner data
You should own the code written for you and your learner data, while a vendor's existing platform and third-party components are normally licensed to you, so the contract must cover each one. "You own it" is five separate questions, and each needs its own answer in writing.
- Source code. Code written for you should be assigned to you on payment. If the build starts from a vendor's platform, that base is normally licensed to you, not assigned. Check that the license is perpetual, lets you modify the code and survives the end of the relationship.
- Third-party components. Almost every build uses open-source libraries, and often paid ones. Ask for the list with each license, attached to the contract, since some carry conditions on how you modify or distribute the software.
- Hosting. Whose account are the servers in? If it is the vendor's, you depend on the vendor for access. Your own account, or your own server, keeps control with you.
- Learner data. It should stay yours. The contract should say so, and say in which format you can export it and how fast.
- Change of vendor. Repository access from the first milestone, not at the end, plus documentation, build instructions and a handover period.
Have counsel review the final wording. For the data side, see our notes on LMS data portability and exit clauses and on self-hosting and data ownership.
Migrating learners, progress and certificates
Courses are the easy half of a migration. Records are the half an auditor asks for, and each type moves differently.
- Users. Accounts, roles, organization structure and managers move as data. Passwords often do not, so plan SSO or a reset at first login.
- Enrollments and completions. These move with their original dates, which must be kept and not replaced by the import date.
- Progress in unfinished courses. The hardest part. A SCORM course's bookmark lives in the old system's player and rarely transfers reliably, so learners either finish in the old system or restart.
- Quiz and exam attempts. Scores and dates move. Answers to individual questions move only if both systems model questions the same way.
- Certificates. Issue dates, expiry dates and certificate numbers, so that a number printed on an old PDF still verifies.
Run a test import into a staging copy. Reconcile counts against reports from the old system: users, enrollments, completions and certificates per course. Fix the mapping and repeat until the numbers match. Then freeze the old system, run the final import and spot-check named people whose history you know. Keep a read-only archive of the old system for as long as your retention rules require.
Other things rarely migrate cleanly either: proctoring recordings stored in a vendor's format, discussion threads and saved report definitions. A partner who says everything will move has not looked yet. Our LMS migration checklist has the full sequence.
How to choose a custom LMS partner
Choose a custom LMS partner by putting the same seven questions to every vendor: the route, who writes the code, ownership, standards, migration, maintenance and what happens if you part ways. Ask us the same ones.
| Question to ask | What a good answer sounds like |
|---|---|
| Which of the three routes do you recommend for us, and why not the others? | A reasoned comparison that includes the case for buying a product |
| Who writes the code? | Named employees. If subcontractors are involved, you are told who and where |
| Who owns the code, and when do we get the repository? | You own the custom work on payment, with repository access from the first milestone |
| Which standards have you implemented, by version? | Specifics such as SCORM 1.2 and 2004, xAPI, cmi5, LTI 1.3 (and which side), SAML 2.0 and SCIM 2.0, shown working |
| How do you migrate learner records? | Test imports, count reconciliation and a written list of what will not move |
| What happens after launch? | A written maintenance scope, and the option to take the work in-house |
| What happens if we part ways? | A handover clause, documentation and nothing that depends on the vendor's accounts |
One more test: if the answer to "should we build?" is always yes, keep looking.
How we do it at LMS Advisor
At LMS Advisor we start with a free consultation, then recommend one of three routes: our LMS as it ships, a custom LMS on our platform, or a build from scratch. We spent 8+ years building, fixing and migrating LMS platforms for other organizations before we built our own.
- LMS Advisor as it ships. Our LMS platform, in our cloud or on your own server, configured and not coded.
- A custom LMS on the LMS Advisor platform. Our LMS is the base and we build your features, branding and integrations on top, in our cloud or on your server. You can have the full source code on your own server with a one-time license option and no subscription. The exact license terms are set in the quote.
- A build from scratch. A new LMS or learning product designed to your specification and not based on LMS Advisor. Our eLearning platform development page covers that route.
We also build custom mobile learning apps for iOS and Android, and we still offer WordPress LMS development services for sites where a plugin is the right size.
What is already built on route two
Starting from a platform means you do not pay to rebuild these:
- Native proctoring configured per exam, with an evidence trail for reviews and disputes.
- A standalone exam center with its own candidate portal and a question bank.
- A certificate designer with automatic issue and a public verification page.
- SCORM 1.2 and 2004, xAPI and cmi5, plus LTI 1.3 as a tool provider.
- SAML 2.0 SSO and SCIM 2.0 provisioning, a REST API and webhooks.
- AI tools that run on Anthropic or OpenAI, chosen by your administrator, which can be switched off.
- An iOS and Android app. A branded version, published under your own Apple and Google developer accounts, is a paid add-on.
How we work
The work is done by our own staff, with no freelancers, under an NDA. You get a dedicated project manager, direct access to the developer and a report at each milestone. Our three guarantees (satisfaction, on-time delivery against the milestones in the quote, and zero billing) are set out on our LMS development services page.
What we do not do
We do not customize Moodle or other open-source LMSs, LMS Advisor has no built-in checkout, and we hold no security certification and claim no WCAG conformance.
- No Moodle or other open-source LMS customization. We can move you out of Moodle: LMS Advisor imports .mbz course backups.
- No built-in checkout in LMS Advisor. Selling courses runs through a WooCommerce store.
- No certifications. We hold no SOC 2, ISO 27001 or HIPAA attestation, and LMS Advisor claims no WCAG conformance. On a custom project, WCAG 2.2 AA or an ASVS level is a requirement you name at the start so that it is scoped and tested.
- No proctored exams in the mobile app. They are taken on a computer.
- Limits in the standards. LTI 1.3 works as a tool provider, not as a platform that launches other tools. The built-in LRS stores xAPI statements while packages run and can forward them to an external LRS, but it is not a reporting LRS you can query.
If you finish this guide thinking you should buy and not build, that is a good outcome. Tell us what you need in the form below and we will say which route we would pick, and why.