A corporate training platform relied on spreadsheets and disconnected tools to run its courses. DXDasia built a custom LMS that centralised course delivery, tracking, and certification — cutting rollout time 3× and lifting completion to 92%.
3× Faster Course Rollout, 92% Completion Rate
The platform was managing course delivery through a patchwork of spreadsheets, email, and a generic file-sharing tool — workable at a small scale, but breaking down as the learner base grew.
We built a custom Learning Management System designed around how the platform actually delivers training, not a generic off-the-shelf tool retrofitted to fit.
The new LMS turned a manual, error-prone process into a self-running system:
Training platforms don’t fail because the content is weak — they fail because the system delivering it can’t scale. Replacing spreadsheets with a purpose-built LMS turned course delivery from a manual chore into infrastructure that runs itself.
The LMS was built on a custom backend with a role-based data model separating learners, courses, and administrators, so permissions and reporting stayed clean as the platform grew. Course content supports video, structured modules, and quizzes, with progress tracked at the module level rather than just “complete/incomplete” — giving admins a real picture of where learners drop off, not just whether they finished. Certification generation and notifications are fully automated, triggered directly off course-completion events rather than run as a manual batch process. The learner portal was built mobile-responsive from the start, since a meaningful share of course completions happened outside a desktop browser.
Tech Stack: React, Node.js, PostgreSQL, AWS S3 for video hosting, built to SCORM/xAPI compatibility standards.
Neither is right by default. The decision turns on how unusual your training logic is, how many systems it must connect to and how long you can wait for the first course to go live.
SCORM dates from 2001 and tracks content launched from an LMS. xAPI is an IEEE-approved standard (IEEE 9274.1.1-2023) in which applications send "noun, verb, object" statements to a Learning Record Store, covering online and offline activity. The same page links cmi5 as the profile for using xAPI with an LMS. If completion and test scores are all you need, SCORM is simpler; if you want activity from mobile apps, simulations or assessments outside the LMS, xAPI earns its extra setup.
| Decision factor | Buy or configure | Build custom |
|---|---|---|
| Standard SCORM hosting and enrolment | Usually covered | Possible, but you maintain it |
| Training logic outside what a product configures | Needs plugins or workarounds | Designed in |
| Standards (SCORM, xAPI, cmi5, LTI) | Check each candidate; xAPI and cmi5 support varies | Can be native |
| Ongoing cost | Licence fees | Maintenance and hosting, indefinitely |
| Time to first course live | Fastest | Slowest |
A decision checklist to test against your own requirements, not independent research.
Completion depends on design as much as content. An analysis of 221 open online courses found rates from 0.7% to 52.1%, a median of 12.6%, lower completion in longer courses and higher completion where assessment was auto-graded only (2015). Those are open courses with unpaid, unsupported learners, so corporate and paid programmes should expect different numbers. The takeaway is to track progress at module level so you can see where learners stop.
Because many learners study on phones, check the learner portal against Google's Core Web Vitals thresholds: LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less at the 75th percentile.
Start from your training logic and your reporting needs, not from a feature list.
When we built reporting for client dashboards, a flat average of rate metrics gave one client a 97.8% engagement rate and sessions of 89.1 seconds. Weighting by sessions gave the true 72.3% and 70.7 seconds. The same trap applies to an LMS: averaging completion across courses of very different sizes hides the small course everyone drops out of. We weight rates by learner numbers before they reach any dashboard.
With the manual bottlenecks removed, the platform now scales by adding courses and departments rather than adding admin headcount — the same system that handled the first cohort handles the tenth without extra overhead. The admin dashboard’s learner-progress data is also starting to shape content strategy: modules with high drop-off rates are now visible immediately instead of surfacing months later through anecdotal feedback, letting the team revise weak content before it affects the next cohort rather than after. What began as a fix for a tracking problem has become the platform’s main source of insight into what’s actually working in the curriculum. It also meant the team could stop treating course updates as a rare, disruptive event — with version control and clear progress data in place, revising a module is now routine maintenance rather than a project.
SCORM is enough if you only need to know that a learner launched content, completed it and scored a result inside the LMS. xAPI becomes worthwhile when you want activity from outside the LMS, such as mobile apps or simulations. It is an IEEE-approved standard, but it takes more setup, so choose it for a reason.
It depends on scope, integrations, the standards you support (SCORM, xAPI) and how many types of learner you have, so no single figure is reliable. A narrower first release gets learners onto the platform sooner. Scope and timing for any DXDasia project are confirmed in writing after a discovery call.
A Learning Record Store (LRS) is the database that receives and keeps xAPI statements, each recording something a learner did in the form of noun, verb and object. It can run on its own or inside an LMS. If you use both, decide which one is the authority for completion records.
Not as a general benchmark. Open online courses studied in 2015 had a median completion of 12.6%, though those learners were unsupported. Paid, cohort-based or employer-mandated programmes behave differently. Set a target from your own history, measure by module, and compare like with like. See our LMS case study for one project's context.
