Learning management system development

Decide from the learning workflow, not a feature list

Every learning platform demonstrates well. They all show a course page, a progress bar and a certificate, so comparing feature lists tells you almost nothing about which one survives your actual process. The useful test is to take one real course and walk it end to end: how it is published, how somebody comes to be enrolled, what they do, how completion is decided, and what happens when the content changes next quarter.

Run that walk-through and the route usually decides itself. If an existing platform handles the workflow, your permissions and your records, configuring it is the cheapest honest answer and we will say so. If it covers the learning but cannot reach the system that holds your customers or your payments, the gap is an integration. Building is justified when the enrolment rules, the completion rules or the reporting are genuinely yours, or when the course catalogue is a commercial asset that has to work like a shop rather than a folder of links.

Structuring courses so they stay maintainable

A course is not a folder of videos. It is a structure with parts that are referenced from elsewhere: modules and lessons, assets that may be reused, prerequisites, an assessment, and a definition of what finishing means. Model that properly and a course can be edited, translated, retired or cloned without anyone rebuilding it. Model it loosely and every change becomes a careful manual operation nobody wants to perform.

The part that catches people is versioning. Courses change while people are part way through them, and the system has to answer what happens next. Does a learner continue on the version they started, or move to the new one? Does a completed record refer to the course as it was on the day it was completed? If somebody failed an assessment that has since been rewritten, what were they actually assessed against? Progress and completion should reference a course version, not just a course, because that is the record you will be asked to defend later.

Finding the right course matters as much as holding it. A catalogue of a few dozen courses can be a list. Once it runs to hundreds, with categories, formats, durations, venues or schedules attached, it needs real filtering and search that matches how buyers actually narrow down, including by course code. Catalogue and search systems covers that layer, and it is usually where a training business wins or loses an enquiry.

Enrolment: where learners come from

Enrolment is the seam between the commercial side and the learning side, and it is worth scoping separately from both. Learners arrive by several routes at once: an individual buying a place, an administrator assigning a course to staff, a company booking seats in bulk, a scheme or employer subsidy that requires its own paperwork, or a waiting list for a dated session. Each route needs a rule for when the entitlement actually starts and what it covers.

That entitlement is the thing to hold, rather than a flag on an account. It has a start, an end where one applies, a course version and a source. When money is involved, payment and checkout owns the transaction and the failure paths around it; enrolment reads the confirmed result rather than guessing from the fact that somebody reached a thank-you page. Where enquiries and bookings also have to reach a sales system, CRM and integrations covers that connection and what has to be confirmed before anyone promises it exists.

Corporate and scheme-supported enrolment is where a Malaysian training provider usually feels the difference. A company booking seats wants one invoice, a named contact who is not a learner, and a view of who attended. A buyer claiming against an employer training scheme needs to know whether a specific programme qualifies before enquiring, and that answer belongs in the catalogue as course data rather than in a paragraph on a landing page. The scheme's own rules and evidence requirements are yours to confirm with the administering body; what the system does is carry the flag, collect the paperwork the enrolment needs, and keep the attendance record the claim will rest on.

A worked course workflow

The table below walks a fictional non-accredited staff course with a single exercise, to show how this kind of scope is written. The actors, rules and responses are assumptions used for illustration, and the last column describes evidence to collect at acceptance rather than tests anybody has passed.

Written this way, a scope becomes reviewable by the people who will live with it. Each row names who acts, what the system does, what happens when it goes wrong, and how you would satisfy yourself that it works. It is also the form we use to agree acceptance, because a launch date is not evidence that a workflow behaves.

Progress, assessment and what completion means

Progress is a record per learner, per course version, not a percentage on a screen. Learners switch devices, lose connections mid-video and come back three weeks later, so the server stays authoritative about what has been done and the interface reflects it. Attempts at an assessment are their own records too: who submitted, when, against which version, and what was returned. Keeping attempts rather than overwriting a score is what makes a later query answerable.

Assessment integrity deserves an honest conversation rather than a feature list. Question pools, time limits, restricted retakes, randomised order and an identity check at submission all raise the cost of casual cheating, and each adds build and support cost of its own. What no platform can do is see who is holding the phone. Decide how much integrity the programme genuinely needs, because a corporate refresher and a qualification that gates someone's job do not need the same controls.

Roles, access and the administration side

Three ideas get confused here and are worth separating: authentication is who somebody is, permission is what their role lets them do, and entitlement is which courses they may reach. A trainer can author without seeing finance. A reporting viewer can read completion without editing content. A learner's access to one course says nothing about another. Accounts and portals covers the sign-in layer these sit on.

Access changes need a trigger and a record, particularly removal: an entitlement that expires, a staff member who leaves, a refunded purchase. The administration side is also where a training operation actually lives, so it deserves the same attention as the learner experience: enrolments and exceptions in queues, progress visible per cohort, and content editable by the team that owns it rather than through a support request to us. Admin dashboards covers those staff views.

What to bring to a scoping conversation

Bring one course and walk it through with us: how it is structured, how people enrol and pay, what completion has to mean, what integrity the assessment needs, which systems have to know about any of it, and the evidence you would want before accepting the work. That is enough to say whether configuring a platform, connecting one, or building is the right route. If you would rather start from the process you run today, talk it through with us.