The LMS mistakes that only show up after launch

Every LMS starts with “it’s just courses and videos”. Then a teacher uploads a 2.1 GB file, a parent wants a refund, a student finishes 80% and expects a certificate, and the support inbox becomes a second product.

We’ve built learning platforms with four portals, paid cohorts, career tools, AI interview scoring, and certificate generation. The features that took the longest weren’t the flashy ones. They were permissions, progress, and payment state.

Mistake 1: treating “student” as one role

A school student, a career switcher buying a ₹499 course, a parent checking progress, and a corporate learner are not the same user. If your permission model has only admin, teacher, and student, you’ll bolt on exceptions until nobody can explain who can see what.

Draw the matrix before the UI. Every cell is a query and a test. If a role can’t be described in one sentence, it’s probably two roles.

Mistake 2: the video player is an afterthought

Serving a 1.5 GB MP4 from your app server is not a course player. It’s a bandwidth bill with a play button. Use object storage plus a CDN, HLS for adaptive playback, signed URLs, resumable progress, and captions.

I wrote the streaming architecture as a separate piece: AWS HLS streaming architecture. The short version: private bucket, transcoding pipeline, CDN, short-lived access.

Mistake 3: “completed” is undefined

Is a course complete when the last video ends? When 80% of lessons are viewed? When the quiz is passed? When the assignment is graded? Each answer creates a different database and a different certificate.

• Define completion per course, not as one global percentage.
• Store progress events, not just a percentage. Events can be audited; a number cannot.
• Make playback progress idempotent. A refresh shouldn’t add another thirty seconds.
• Handle timezone changes, multiple devices, and offline viewing.
• Show students exactly what is left, not just a bar.

Mistake 4: certificates anyone can fake

A certificate is a trust document. If it’s a PNG with a name typed on it, employers can’t verify it and your brand carries the risk.

The verification page is the feature. The PDF is the souvenir.

Mistake 5: payment webhooks that enroll twice

Razorpay and Stripe retry webhooks. If your handler isn’t idempotent, one payment creates two enrollments, two invoices, or two wallet credits. Use the provider event ID as a unique key, verify the signature, and make the database write transactional.

• Verify the webhook signature before trusting the payload.
• Store the provider event ID with a unique constraint.
• Handle failed payments, delayed authorisation, and refunds.
• Revoke access according to a written refund policy, not an ad-hoc email.
• Model credits as a ledger with entries, not one mutable balance column.
• Reconcile provider settlements against enrollments every week.

ElyteSpark uses a credit wallet for pay-per-session interviews. That kind of balance needs a ledger — debit, credit, reason, reference — not a single number someone can overwrite.

Mistake 6: no teacher workflow

Teachers don’t upload one video. They upload forty, reorder modules, fix a typo in lesson twelve, schedule a drip release, answer questions, and ask why payouts are late.

• Bulk upload with processing status and clear failures.
• Draft, preview, publish, and unpublish without deleting history.
• Version a course so a certificate can reference what was actually completed.
• Drip schedules in the teacher’s timezone.
• A Q&A queue with notification and moderation.
• An earnings report that matches the payment provider.
• A student roster export for offline support.

Mistake 7: student data treated casually

An LMS may handle minors, resumes, interview recordings, payment data, and health information in one product. That’s not a privacy-page problem; it’s a data-map problem.

• Collect only what the learning experience needs.
• Record consent and purpose where required, especially for minors.
• Set retention rules for recordings, resumes, and assessment notes.
• Log admin access to sensitive records.
• Provide export and deletion paths.
• Review vendor terms before sending student data to an AI or analytics tool.

Mistake 8: launching without support paths

The top five tickets are predictable: can’t log in, payment succeeded but no access, video won’t play, certificate name is wrong, refund requested. Write the scripts and admin actions before day one.

• A support inbox with order/enrollment lookup.
• One-click resend of access and receipt emails.
• An admin action to fix a certificate name with an audit note.
• A documented refund and access-revocation policy.
• A video-delivery status page for processing failures.
• A status page for platform incidents.

A launch checklist that saves a quarter

1. Model every role and permission, including support and parents.
2. Define completion per course and test multi-device progress.
3. Test video on a mid-range Android phone and a slow connection.
4. Verify webhooks, retries, refunds, and duplicate events.
5. Generate a certificate and verify it publicly.
6. Run a refund and access-revocation drill.
7. Test teacher bulk upload and a failed transcode.
8. Export the student roster and check the columns.
9. Review data retention and AI vendor flows.
10. Write the top ten support replies.
11. Load-test enrollment and certificate generation.
12. Run a small paid cohort before the big launch.

What two very different platforms taught us

Kristive runs four portals — admin, teacher, student, parent — with courses, payments, and certificates. ElyteSpark combines courses with mock interviews, resume checks, job discovery, and credits. The lesson from both: the product is not the video player. The product is the confidence that access, progress, and proof are correct.

Build the player last

Build the course player last. Before it, write the role matrix, the completion rules, the payment state machine, and the certificate verification path. Those four documents will save more time than a prettier dashboard ever will.