A study of 221 MOOCs put the median completion rate at 12.6 percent, with the full range running from 0.7 percent to 52.1 percent. A 2019 MIT analysis found its own courses finishing closer to 3 percent. One early Coursera course on bioelectricity certified 350 people out of 12,700 who enrolled, and lost roughly 80 percent of them before the course even started. These were not amateur projects. They were built by the best-funded institutions on earth, hosting some of the best instructional content ever produced, on platforms with effectively unlimited engineering budgets. And nine out of ten people walked away. If that is what the best content in the world delivers, then content was never the bottleneck — and most e-learning software is being built to fix the wrong problem.
The checklist that builds dead platforms
Almost every e-learning software project starts the same way: a feature list. SCORM compliance, a video host, a quiz engine, badges, points, leaderboards, certificates, a discussion feed, a mobile app, maybe a 'gamification layer.' The buyer believes — and the average vendor is happy to agree — that more features mean a better learning product. So the budget goes into the course player: the thing that displays a lesson, plays a video, and ticks a box when you reach the end. It is the part everyone can picture, so it is the part everyone specs.
Here is the uncomfortable part. The course player is a commodity. A competent team can stand one up in weeks, and there are open-source and off-the-shelf versions that are already better than whatever you were going to build. If features were the thing that made people learn, the 13,000-plus university MOOCs catalogued by 2019 would have cracked completion years ago. They had every feature. They still finish 12 percent of the room. You cannot out-feature a problem that features do not touch.
What an e-learning product actually is
My position, after eleven years of building software people actually use, is blunt: an e-learning product is not a content-delivery system. It is an operations-and-behavior engine that happens to have content inside it. The hard, valuable, defensible parts are the ones nobody puts on the slide — routing the right learner to the right next thing, scheduling, payments, identity, progress modelling, and the instrumentation that tells you who is about to quit. The video player is the visible 10 percent. The product is the other 90 percent, and it is mostly invisible.
We learned this concretely on HeyTutor, an EdTech marketplace we have been the engineering partner on since 2016. The founders arrived with a one-page spec. The real product turned out to need about forty pages — and almost none of the difference was 'play a lesson.' It was matching learners to tutors, vetting, scheduling, payments, dispute handling, and the admin machinery that lets the operation actually run at scale. The thing that grew into one of the larger US tutoring marketplaces was a logistics system with education on top, not a content viewer with a booking form bolted on.
Completion is an engineering problem, not a content problem
The MOOC data is brutally specific about where learners die: the first two weeks. Engagement and assignment submission fall off a cliff early and then flatten — the people who survive the opening stretch tend to finish. The same data shows courses with auto-graded, structured assessment completing better than open-ended ones, and very large cohorts completing worse than small ones. None of that is a content insight. It is a systems insight. It says the product's job is to detect a learner stalling in week one and do something about it before they close the tab.
That is an instrumentation and data-engineering problem, and it is exactly the work that gets cut first because it does not demo well. Most platforms I have seen cannot answer the only question that matters — 'who is stuck right now, and on what?' — because nobody funded the event tracking, the progress model, and the analytics loop that would tell them. That loop is unglamorous. It is also the entire moat. A platform that knows when to intervene beats a prettier platform that doesn't, every single time, and it is the part the feature checklist never has a line item for.
Personalization beats production value
The other thing the content-first reflex gets wrong is assuming the answer is more or better material. It usually isn't. We built MOTTIV from scratch — a product that generates personalized endurance-training plans — and the value was never a library of workout videos. It was the engine that adapts the plan to the individual and keeps adapting as they progress. That generalizes cleanly to e-learning: a smaller body of content, correctly sequenced and adjusted to where a specific learner actually is, finishes better than a vast catalogue everyone gets identically. Adaptive sequencing is software, not film production.
The AI tutor is the new badge
The current version of the feature-checklist mistake is the AI tutor. Bolt a chatbot onto the LMS, call it 'adaptive,' put it in the deck. The chatbot is the new gamification badge: it demos beautifully and changes nothing about whether anyone reaches the end. We run a growing AI and ML practice — RAG systems, agents, the real machinery — and the test we hold it to is the only honest one in this field. Does it move completion? AI earns its place when it closes the feedback loop: grading and explaining a wrong answer in the moment, sequencing the next lesson, catching the week-one stall and nudging. It does not earn its place as a mascot in the corner of the screen. Treat it as a reviewed accelerator pointed at a metric, not a feature you can be seen to have.
If 'viable' is doing unexamined work in your plan, what an MVP in software actually means is worth ten minutes. Our EdTech development work cover the build side.
What this means when you actually build one
Build the operations engine first and treat the player as plumbing you can swap. In budget terms, a serious e-learning platform with matching, scheduling, payments and real instrumentation is a marketplace-class build — realistically the 80,000-to-200,000-dollar range for a first production version, and the number is driven by the routing, payments and analytics complexity, not by the lesson screen. If a vendor's estimate is dominated by the course player, they are quoting you the cheap, commodity 10 percent and quietly under-scoping the part that decides whether the thing works.
Scope discipline matters more here than almost anywhere, because the temptation to build the whole catalogue and every badge is overwhelming. One of our rescues — a stalled build we took over — took a full week of cutting 30 to 50 percent on each pass to find the smallest version that actually shipped value. E-learning needs that ruthlessness: ship the smallest loop that proves a real learner gets to the end, instrument it, then expand. And it rewards continuity — the completion instrumentation is institutional knowledge, which is why a partnership like HeyTutor running nine-plus years with the same team beats a platform handed between vendors who each rebuild the analytics from scratch and learn nothing.
So here is the whole argument in one line: if you are specifying your e-learning product by its feature list, you are building a 12-percent platform. The course player is solved and it was never the point. Put the money, the senior engineers and the design effort into the engine that notices a human being struggling in week one and does something about it — the matching, the sequencing, the instrumentation, the loop. That is the product. Everything else is a video tag.