Why LMS builds break, and the four faults we find most

LMS projects have a failure pattern that is different from ordinary WordPress work, and agencies that build them occasionally tend to get caught by the same four things.

The reason is structural. A marketing site is mostly presentation. An LMS is an application with state: who is enrolled, what they have completed, what they are allowed to see, and what happens when they pay. Bugs in presentation are visible. Bugs in state are silent, and they are usually discovered by a student who cannot get into a course they have already paid for.

The short version:

• LMS faults are invisible from the front end and involve people who already paid
• The most expensive rescues trace to a post type conflict with LMS core
• Access control breaks in the awkward states nobody tests: expired, cross-course, logged out
• If learners include children, COPPA changes what you may build and collect

Here is what actually goes wrong, in rough order of how often we are called about it.

Custom post type conflicts with LMS core break enrolment silently#

This is the one that produces the most expensive rescues, because it is invisible from the front end and it does not look like a bug.

LMS plugins register their own post types, taxonomies and rewrite rules. A theme or a second plugin registering something with a conflicting slug, or claiming the same rewrite, will break enrolment or course access while leaving everything else working perfectly. Courses list. Lessons render. Checkout completes. Access never gets granted.

Teams debug this from the front end for weeks because the front end is where the symptom is. It cannot be found there. The fix takes an afternoon once you look at what is registered and in what order, and the diagnostic time is nearly all of the cost.

The prevention is a rule rather than a technique: on any LMS build, namespace every custom post type and taxonomy you register, and check the rewrite rules after activating anything new.

Test LMS access control as a matrix, not as an admin#

Every LMS build has a set of rules about who can see what. Enrolled students see lessons. Non-enrolled visitors see a sales page. Expired members see a renewal prompt. Administrators see everything.

Almost nobody tests these as a matrix. They test as a logged-in administrator, which is the one account that bypasses every rule in the system, and then they test one student account that is correctly enrolled.

The states that break are the awkward ones: a user who enrolled and then expired, a user enrolled in course A trying a direct URL for course B, a logged-out visitor with a lesson link from a friend, and a user whose payment failed after access was granted. Build the matrix before you build the site, and walk it before handoff. It takes an hour and it catches the faults that otherwise arrive as angry support tickets.

Payment and enrolment are two events: log them separately#

They are two events, and the gap between them is where money disappears.

Payment succeeds at the gateway. Enrolment is granted by the LMS. Anything that interrupts the sequence between them, a timeout, a plugin conflict, a webhook that did not fire, leaves a student who has paid and cannot get in. They will email support, and support will not have a way to see what happened.

What we build in as standard: log both events separately, make failed enrolments visible somewhere an administrator will actually look, and give support a manual enrolment path that does not require a developer. That last one costs almost nothing and removes most of the panic from the first month after launch.

Design the course hierarchy for sixty courses, not six#

The launch catalogue is usually small. Six courses, a few modules each, and any structure works.

The structure has to hold at sixty courses. Can a student find what they need? Can an administrator reorder a module without breaking progress records? Can you add a prerequisite later, or was that decision baked into how lessons were nested? Is progress tracked per lesson, per module, or per course, and does that match how completion certificates need to work?

Retrofitting a course hierarchy after students have progress data is genuinely difficult, because the data has to migrate with it. Decide it before you build, and specifically ask the client what the catalogue looks like in two years rather than at launch.

COPPA compliance and video hosting: decide both before building#

Legal exposure when learners are minors. If the platform serves anyone under thirteen in the US, the requirements change: parental consent, what you may collect, and what your privacy policy has to say. This is not something to discover after launch. Ask on the first call who the learners are, and if the answer includes children, price the legal pages and consent flow as real work.

Video hosting decided at the end. Self-hosting course video will destroy the hosting plan the site was quoted on. It also affects completion tracking, because the player determines what progress events you can capture. Decide the video approach during scoping, alongside the content structure, not during the week you are trying to launch.

LMS build checklist: four habits that prevent rescue projects#

LMS builds are not harder than marketing sites in the way people expect. The build is often simpler. What makes them unforgiving is that the failures are invisible from the front end and they involve someone who has already paid.

Test the access matrix. Log payment and enrolment separately. Namespace everything you register. Decide the content hierarchy before students generate progress data. Four habits, and they remove most of the reasons these projects go wrong.

Frequently asked questions#

Why can students pay but not access their course?#

Because payment and enrolment are separate events. The gateway confirmed payment, then something interrupted the enrolment grant: a webhook that did not fire, a timeout, or a plugin conflict. Log both events separately and give support a manual enrolment path.

What is a custom post type conflict in an LMS?#

An LMS plugin registers its own post types and rewrite rules. A theme or second plugin registering a conflicting slug or rewrite can break course access while everything else works. It is invisible from the front end, which is why teams debug it in the wrong place for weeks.

What does COPPA require for an e-learning site?#

If the platform serves children under thirteen in the US, it needs verifiable parental consent, restrictions on what data is collected, and privacy documentation written for that audience. It changes the build, so it has to be identified during scoping rather than after launch.