Publishing an online course used to take a week at Unyleya. Here’s what was actually causing that, and what happened when we fixed it.
A week sounds like an exaggeration. It wasn’t. It was the real, measured, nobody-was-happy-about-it cycle time for taking a course from “content ready” to “students can enroll.” When I started mapping the workflow, I found all the usual suspects: sequential approvals that could have been parallel, manual steps that existed because at some point someone had decided a spreadsheet was good enough, handoffs between departments that assumed the previous step had finished but didn’t verify it, and QA processes that duplicated work already done upstream.
None of those things had been designed to be slow. They’d just accumulated, each step added to address a real problem, none of them reconsidered as a system.
The Business Cost of Slow Publishing
At Unyleya, the education model was distance learning — online courses across a catalog that needed to keep growing to stay competitive in a crowded market. The faster you can publish courses, the more content you can get to market, the more programs you can offer, the more students you can enroll. Publishing velocity was directly connected to revenue.
When courses took a week to publish, the pipeline had a permanent backlog. Content that was ready to go sat waiting for its turn through the approval chain. New programs that could have been available in January were launching in March. That lag had a cost, even if it was difficult to put a specific number on it in real time.
The 31-minute publishing cycle we achieved wasn’t an estimate or a best-case scenario. It was a measured result from the rebuilt system.
🚧 Need more context: How was the 31-minute number measured — what defined the start and end of the publishing cycle? What were the specific bottlenecks in the original week-long process, and in what order were they addressed?
What the CMS Actually Changed
The rebuilt course publishing platform had three main components:
Template-based course creation. Instead of building each course from scratch — configuring LMS settings, uploading content in the right formats, setting up navigation and assessment rules manually — instructional designers worked from templates. The decisions that were the same every time were made once, in the template. The decisions that were unique to each course were the only ones that required human input.
Automated QA checks. A meaningful portion of the original week was spent on quality review that was genuinely necessary — checking that content displayed correctly, that assessments triggered properly, that completion rules worked. Most of those checks were mechanical. We automated the mechanical ones, which meant human QA time could focus on judgment calls rather than checkbox verification.
Single-click publishing to LMS. The final step in the original workflow involved manual LMS configuration — the kind of work that required specific technical knowledge, could only be done by certain people, and introduced errors whenever those people were sick or on vacation. We replaced it with a publish action that handled LMS configuration automatically based on the course template and metadata already entered.
🚧 Need more context: What LMS was Unyleya using? What did the technical architecture of the CMS look like? Who built it — internal team or with an external partner?
The Netflix Parallel
The publishing platform solved the content production problem. We also rebuilt what students saw on the other side.
The existing LMS presented courses the way most LMSes did in 2018: as a catalog list. You enrolled, you saw your courses in a list, you clicked into one, you worked through it. Functional. Not particularly inviting.
We redesigned the student experience with a content-discovery model closer to what students were already used to from streaming platforms: featured content, curated sections, recommendations based on area of study, visual browsing rather than list scanning. The idea was that the library Unyleya had built was genuinely valuable, and students would engage with more of it if they could actually discover it.
🚧 Need more context: Did the redesigned student interface drive measurable changes in enrollment or course completion rates? Were there specific content categories that saw increased engagement after the redesign?
Mobile Strategy
In 2018-2019, expecting students to primarily access course content on desktop was already out of step with how people actually learned. Unyleya’s student population was using mobile devices. Building for mobile-first wasn’t a feature — it was table stakes for reaching the actual audience.
🚧 Need more context: What did the mobile app cover — full course access, or a subset? Was it a native app or web-based?
The 200% Number
Unyleya grew revenue by 200% during this period. The CMS modernization was one lever among several — you can’t isolate a single variable cleanly in business growth. But the connection is real: faster publishing meant more courses on the platform, which meant more enrollment options, which meant more students. The pipeline that had been perpetually backed up started moving.
🚧 Need more context: What was the team size working on the platform? What was the timeline from project start to the 31-minute publishing result? What other factors drove the revenue growth during this period?