Choosing a Custom LMS Development Company: 15 Questions to Ask
To choose a custom LMS development company, ask 15 questions across four areas: proof and fit, technical depth, delivery and contract terms, and life after launch. Score each answer against evidence the company can show you, such as a reference, a sample document or a contract clause, not against how confident the sales call felt.
Most buyers compare vendors on price and portfolio screenshots. That misses what decides whether you can run, change and eventually leave the platform: who owns the code, which learning standards it speaks, and what happens when the original team moves on. Each question below includes what a strong and a weak answer sound like, followed by a scoring sheet you can reuse.
One disclosure: Mundrisoft says it specializes in building custom enterprise-grade LMS platforms, so we are the kind of company you might be scoring. Use the same sheet on us.
Key takeaways
- Judge answers by evidence you can inspect, not by promises made on a call.
- Ownership, exit terms and post-launch support are the questions vendors answer least clearly, so weight them heavily.
- Send every company the same written brief so the answers can be compared line by line.
- Score each answer 0, 1 or 2, apply weights, and pause any company that scores 0 on a high-weight question.
- Pay for a short discovery phase before committing to a full build.
How should you run these 15 questions?
Send the same written brief to three companies, ask all 15 questions in writing first, then repeat them on a call. Request one piece of evidence per answer. Written answers can be compared side by side and later copied into the contract. Spoken answers drift.
Put the questions to the people who would do the work. A sales lead can answer questions 1 to 4 and 10. Questions 5 to 9 and 11 to 12 need an engineer or delivery manager in the room.
What should a custom LMS development company prove before you shortlist it?
It should prove that it has built something like your platform, that named people will build yours, that it can scope the work before pricing it, and that it will tell you when not to build. These four questions filter out most unsuitable companies in the first call.
1. Which custom LMS have you built for a team like ours, and can we speak to that client?
Strong: Describes the client type and what was built, offers a reference call and a demo environment, and volunteers what went wrong and how it was fixed. Weak: Shows a portfolio of unrelated apps, cites confidentiality for everything, or offers only design mockups.
2. Who will work on our project, and how long have they been with you?
Strong: Names roles and people, explains how the team is staffed, and says what happens if the lead leaves. Weak: “Our team of experts” with no names, or a lead you meet once during sales and never again.
3. How do you turn our requirements into a scope we can price?
Strong: Proposes a paid discovery phase with deliverables: user roles, workflows, an integration list and a prioritized backlog. Weak: Quotes a fixed price after one call, or says “we will figure it out as we go.”
4. Which parts of our brief would you challenge or leave out?
Strong: Names features better bought as services or deferred, explains the trade-off, and admits when an existing LMS would do. Weak: Agrees to everything. A company that never pushes back prices every feature and finds the problems later.
Which technical questions separate a capable team from a generic one?
Ask about standards, integrations, security, accessibility and architecture, and ask for artifacts rather than adjectives. A capable team can name the specifications it implements, show how it tests them, and describe how third-party components are chosen and licensed. A generic team answers with slogans.
5. Which learning standards will the platform support, and how will you prove it?
Strong: Asks which standards you actually need (SCORM, xAPI, LTI, cmi5), plans tests with real content packages and names the Learning Record Store it will use. For tool connections it mentions LTI 1.3 and certification. Weak: “We support all standards,” or “we can add that later” with no test plan.
These are specifications, not tick-box features. xAPI, maintained by ADL, defines how learning activity is recorded and sent to a Learning Record Store. LTI 1.3 from 1EdTech is built on OAuth2 and JSON Web Tokens, and its LTI Advantage services cover grades, user rosters and deep linking. 1EdTech also offers a certification suite for LTI Advantage.
6. Which systems will it connect to, and who maintains those connections?
Strong: Lists your HR system, CRM, single sign-on, payments and video tools, explains API versus file sync, error handling and monitoring, and says who fixes an integration when a third party changes its API. Weak: “We integrate with anything,” with all integrations priced as one line.
7. How do you build and test for security, and where will learner data live?
Strong: Names a framework such as the OWASP Application Security Verification Standard, which lists use during procurement as one of its intended uses. Describes code review, dependency scanning, an independent penetration test, role-based access, data location and breach notification duties under laws such as GDPR. Weak: “Bank-grade encryption,” or security treated as a final-week task.
8. Which accessibility target will you build to, and how will you test it?
Strong: Commits to a named target such as WCAG 2.2 at a stated level (A, AA or AAA), tests with automated tools plus manual keyboard and screen reader checks, and delivers a written report. Weak: “We follow accessibility best practice.”
Pro tip: Split the call. Put proof and pricing questions to the account lead and the technical questions to the engineer who would own the build. Where the two answers differ, you have found what is being oversold.
9. How is the platform designed to grow, and which third-party components does it use?
Strong: Explains hosting, multi-tenancy if you need it, a load-testing plan, and supplies a component list with licenses. If AI features are in scope, says which data goes to which model and how output quality is checked; Mundrisoft’s AI solutions page lists the AI services Mundrisoft offers. Weak: “Cloud-native and scalable” with nothing measurable.
Which delivery and contract questions protect your budget?
Ask how scope changes are priced, how “done” is defined, how often you see working software, and who owns what you paid for. Clear answers on these four points keep the budget predictable, and vague ones are the first sign of trouble.
10. How is the work priced, and what happens to cost when scope changes?
Strong: Explains fixed price, time and materials or a hybrid and when each fits, shows the change-request process and a rate card, and lists exclusions such as hosting, licenses and content migration. Weak: One lump sum with no exclusions, and change requests priced ad hoc.
11. How will we know a feature is done?
Strong: Written acceptance criteria per feature, automated tests, a staging environment for your own acceptance testing, and defined defect severities with fix windows. Weak: “QA is handled internally,” with no test evidence shared.
12. What does the delivery plan look like, and how often will we see working software?
Strong: Milestones tied to demos of working features at regular intervals, a list of what you must supply (content, SSO access, test users) and a risk register. Weak: A single date at the end, or a plan that assumes you will never change your mind.
13. Who owns the source code and the data, and which licenses apply to what you reuse?
Strong: A written clause assigning the code written for you, a schedule of pre-existing tools and open-source components with their licenses, and confirmation that your data and exports belong to you. Weak: “We will license the platform to you,” or ownership “to be discussed later.”
Do not assume a “work made for hire” clause settles this. The US Copyright Office’s Circular 30 says a commissioned work qualifies only if it falls in one of nine listed categories and both parties sign a written agreement saying so. Software is not named among those categories. Ask for an explicit assignment, and have a lawyer in your country review it.
What should happen after launch, and if you leave?
A custom LMS needs patches, dependency upgrades and fixes for years, and you may one day want a different team. Strong companies put support terms and handover duties in writing before work starts, because the cheapest time to agree on an exit is before you need one.
14. What does support look like after launch, and what does it cost?
Strong: A service-level agreement with response and resolution targets by severity, a security patching duty, a plan for upgrading dependencies, a defined warranty period and a published price list. Weak: Support “as needed,” no patching commitment, and a price revealed only after go-live.
15. If we part ways, what do we receive, and how quickly?
Strong: The complete repository, infrastructure definitions, architecture and runbook documents, data exports in open formats, and a handover period with named staff, all written into the contract. Weak: Documentation “on request,” code kept in the vendor’s repositories, or fees charged for exports.
Pro tip: Test the exit on paper. Ask for a sample handover pack from a past project, with the client’s permission, and have an engineer outside the vendor read it for an hour. If that person cannot explain how to deploy and restore the system, the exit clause is theoretical.
Which red flags should end the conversation?
Stop when the behavior around the answers is wrong, even if the answers sound good. The patterns that matter concern how the company treats evidence and commitments, not any single weak reply. Five behaviors are enough reason to walk away or to demand a written fix first.
- Written answers differ from what was said on the call.
- Nothing can be shown running, only slides or mockups.
- Every reference is unavailable “for confidentiality.”
- A discount appears if you sign before you finish comparing.
- Contract terms on ownership, support or exit are deferred until after signature.
How do you compare each custom LMS development company on one scoring sheet?
Score every answer 0 (no answer or no evidence), 1 (a credible claim without proof) or 2 (a clear answer backed by evidence you checked). Multiply by the weight, add the totals, and compare vendors on the same sheet. The weights below are a starting point, not a standard.
| # | Area | Weight (1-3) | Evidence to request |
|---|---|---|---|
| 1 | Relevant LMS experience | 3 | Reference call, demo environment |
| 2 | Named team | 2 | Roles, names, staffing plan |
| 3 | Discovery and scoping | 2 | Sample discovery deliverables |
| 4 | Willingness to push back | 1 | Items they would defer or buy instead |
| 5 | Learning standards | 3 | Test plan with real content packages |
| 6 | Integrations | 3 | API documentation, monitoring approach |
| 7 | Security | 3 | Named framework, penetration test summary |
| 8 | Accessibility | 2 | Target level, sample test report |
| 9 | Architecture and components | 2 | Component list with licenses, load-test plan |
| 10 | Pricing and change control | 3 | Rate card, change-request process, exclusions |
| 11 | Testing and acceptance | 2 | Acceptance criteria template, staging access |
| 12 | Delivery plan | 2 | Milestone plan, risk register |
| 13 | Code and data ownership | 3 | Draft ownership clause, license schedule |
| 14 | Post-launch support | 3 | Draft service-level agreement, price list |
| 15 | Exit and handover | 3 | Sample handover pack, export formats |
The weights add up to 37, so the maximum score is 74. Totals alone can mislead. Imagine a company that scores 2 on every question except a 0 on question 13. It totals 68 of 74 and looks excellent, yet you do not know who owns the platform. So add one hard rule: a 0 on any weight-3 question pauses that vendor until the gap is closed in writing.
Read more: Build vs buy TMS
Adjust the weights to your risk. A regulated training provider might raise security and accessibility to 3, while a small team with no integrations might lower question 6.
What should you do next?
Write a two-page brief: your learners and administrators, the five workflows that matter most, the systems you must connect, and the standards you need. Send it with these 15 questions to three companies, and give them the same deadline.
Score the written answers before any follow-up call, then use the calls to test the weakest scores. Fund a short paid discovery phase with your top choice before you sign a full build.
If you want Mundrisoft on that shortlist, our eLearning solutions page describes the learning platforms we design and implement and how we integrate them with LMS, assessment and CRM systems. Send us the same brief and the same questions, and score us like everyone else.
Frequently asked questions
How many companies should I compare for a custom LMS?
Three is a practical number. Two gives you little contrast, and more than four makes written comparison slow without adding new information. Brief them identically, set one deadline, and score the written answers before any call. If all three score badly on the same question, your brief probably needs work.
Should a custom LMS be fixed price or time and materials?
Fixed price suits a well-defined scope that a discovery phase has already documented. Time and materials suits uncertain scope but needs tight reporting and a budget cap. A hybrid is common: fixed price for discovery and a first release, then time and materials. Whichever you pick, require a written change-request process.
Is a paid discovery phase worth it?
Usually yes. Discovery turns your wishes into user roles, workflows, integrations and a prioritized backlog, so the quote reflects real work. It also lets you test how the team communicates before committing. Make sure the contract says the deliverables are yours, so you can take them to another company if the fit is poor.
Which standards should a custom LMS support?
It depends on your content and tools. SCORM matters if you have existing packages, xAPI if you need detailed activity records in a Learning Record Store, and LTI 1.3 if you plan to connect third-party tools. Ask the company to explain which of these you need and how it will test them.
Who should own the source code of a custom LMS?
Most buyers want ownership of the code written for them, with licenses listed for any pre-existing or open-source components. Ownership rules vary by country and a work-for-hire clause may not be enough on its own, so ask for an explicit assignment clause and have a lawyer review the contract.
When is a custom LMS the wrong choice?
Custom is the wrong choice when an existing product already covers your needs with configuration, because you will pay to build and maintain what you could rent. It fits better when your workflows, integrations or compliance rules are specific enough that off-the-shelf tools need constant workarounds.