When a custom LMS makes sense
SaaS LMS platforms like TalentLMS, Docebo, and Absorb are excellent products for organisations with standard training workflows. They are fast to deploy, well-supported, and continuously updated. For the majority of corporate learning use cases, they are the right choice.
A custom-built LMS makes sense when: - You need a white-label product with your brand and domain, not a vendor's subdomain - You have multi-tenant requirements that need organisational separation at the database level - Your compliance reporting needs are specific enough that no existing platform covers them - You are building a commercial LMS product that you will sell or license to customers - Your integration requirements — HRIS, CRM, SSO, payment gateway — exceed what the platform's API can deliver - You need per-learner theming, content personalisation, or adaptive learning paths at a level that requires custom logic
Phase 1: Discovery and architecture
User research
Before writing a line of code, interview the people who will use the system. Administrators, course authors, and learners have different priorities and pain points. What does an administrator spend the most time doing? What makes learners abandon courses? What reports does the compliance team need every quarter?
This research shapes every architectural decision that follows.
Data architecture decisions
The most important early decision is tenancy model. A single-database multi-tenant model (all tenants share a database, rows are filtered by tenant ID) is simpler to build and operate. A schema-per-tenant model offers stronger data isolation and easier tenant migration. A database-per-tenant model offers the strongest isolation but the highest operational overhead.
For most commercial LMS products, schema-per-tenant offers the right balance of isolation and operational simplicity.
Technology stack
For a modern custom LMS, we typically recommend: - Frontend: Next.js 14 with the App Router for the learner-facing portal and admin interface - Backend API: Node.js with Express or Fastify, TypeScript throughout - Database: PostgreSQL for structured data, Redis for session management and caching - File storage: S3-compatible storage for course content, videos, and documents - Video: Mux or Cloudflare Stream for adaptive video delivery - Search: Meilisearch or Elasticsearch for course and content discovery
Phase 2: Core feature development
Authentication and authorisation
A proper LMS needs role-based access control at multiple levels: system admin, organisation admin, course admin, instructor, and learner. Build the permission model before anything else — retrofitting RBAC onto a system that was not designed for it is painful.
For SSO, implement SAML 2.0 and OAuth 2.0 / OIDC from the start. Enterprise customers will require SSO, and it is far easier to design the authentication layer to support it than to bolt it on later.
Course content and SCORM
If your LMS needs to host content from external authoring tools (Articulate Storyline, Adobe Captivate), you need SCORM support. SCORM packages communicate with the LMS via a JavaScript API — your LMS frontend needs to implement the SCORM API and the backend needs to store and retrieve learner data (completion, score, time, bookmark) against a specific learner-course-attempt record.
For SCORM 1.2, the API implementation is straightforward. SCORM 2004's sequencing rules are significantly more complex and most organisations do not need them.
Progress tracking and completion logic
Define your completion model carefully before building it. Does completing all modules equal course completion? Or passing an assessment? Or spending a minimum time in the content? Different organisations have different answers, and compliance requirements often dictate specific completion criteria. Build a flexible completion rules engine rather than hard-coding a single model.
Reporting and analytics
Learning analytics is where many LMS platforms fall short of enterprise needs. Build your reporting layer on a dedicated read model — a denormalised database or data warehouse that is optimised for query, not for transactional operations. This prevents reporting queries from impacting the application database performance.
Essential reports: completion rate by course, by team, by time period; assessment score distributions; time-to-completion benchmarks; compliance status by individual and department.
Phase 3: Integrations
HRIS integration
If your LMS needs to stay in sync with your HR system — creating learner accounts when employees join, deactivating accounts when they leave, syncing team structure for reporting — you need a reliable sync mechanism. Webhooks from the HRIS (if available) are preferable to scheduled batch sync. Whatever approach you use, design for the failure case: what happens when a sync fails, and how do you detect and recover from drift?
Payment and enrolment
For commercial LMS products that charge for course access, you need a robust enrolment and payment model. Use Stripe for payment processing — their hosted checkout and subscription billing handles most payment scenarios. The LMS side needs to model course licences, seat counts, renewal dates, and access expiry correctly.
Phase 4: Testing and launch
Learner acceptance testing
Before launch, test the full learner journey with real users on real devices. The three most common launch issues: course content that looks correct in the authoring tool but breaks in the SCORM player, completion logic that behaves differently than expected, and mobile experiences that were not adequately tested.
Performance testing
Load test before launch, not after. Simulate your expected concurrent user count plus 2x headroom. LMS systems see traffic spikes at specific times — morning training sessions, compliance deadline weeks, new employee intake dates. Your infrastructure needs to handle these peaks.
Timeline and cost expectations
A properly scoped custom LMS build for an organisation with standard requirements (single tenant, standard SCORM support, basic reporting, SSO) typically takes 12–16 weeks and costs £40k–£80k at market rates. Multi-tenant commercial products with advanced analytics and integrations are 20–30 week projects in the £80k–£150k range.
These are meaningful investments. They make sense when the platform is a core part of your product or service, when you need capabilities that no off-the-shelf product provides, or when the long-term cost of SaaS licensing exceeds the cost of a custom build over a 5-year horizon.