# Aladia Online Learning Platform

> Italian EdTech platform for cohort courses, live classes, and creator monetization — running live at aladia.io with 2,000+ registered students.

- URL: https://oliverz.dev/work/aladia-online-education-platform
- Author: Oliver Zhang (https://oliverz.dev)
- Language: en
- Category: EdTech
- Year: 2024
- Role: Frontend Engineer
- Client: Aladia S.r.l. (Italy)
- Stack: React, EdTech, Stripe, OAuth
- Live: https://app.aladia.io/

## The brief

Aladia is an Italian online learning platform covering cohort courses, live classes, AI-assisted course creation, and creator monetisation. Aladia's product team led direction, design, and platform architecture. I built the frontend surfaces learners and instructors use, roughly 800 engineering hours. It runs at [aladia.io](https://app.aladia.io/) with 2,000+ registered students.

![The course detail page](https://oliverz.dev/works/aladia-online-education-platform/1.png "Chapter list with per-lecture lock states and scheduled live dates, over a video hero, with pricing and enrolment in the same view")

## One page carrying too many states

The course detail page above is the surface I spent the most time on, because it has to hold several things at once without confusing anyone.

Look at the sidebar. Chapter 2 is expanded and running, its first two lectures ended, lectures 3 through 6 scheduled for specific dates and times. Chapter 3 is locked. Each row carries its own state: watchable, ended, scheduled for a date, or locked behind enrolment. Meanwhile the footer shows rating, language, seat count, live-lecture count, price, discount, and a countdown.

Cohort courses cause this. An on-demand course is a list of videos, all available, all identical in state. A cohort course has a calendar, so the same page must serve a prospective buyer deciding whether to enrol, a current student finding tonight's class, and someone who missed lecture 2 and wants the recording. Getting the lock and schedule states legible at a glance took more iteration than the video player, the chat, or the checkout.

## Checkout inside the decision

The Stripe checkout sits in the course detail experience rather than on a separate page. Someone weighing a course against its price and start date should not lose that context to a checkout route, then have to rebuild their reasoning if they come back.

## Instructor-side creation

I built both creation flows: on-demand course setup with content upload and chapter configuration, and live class scheduling.

These flows decide whether the catalogue grows. A platform whose instructors find course creation painful runs out of content, and no amount of consumer-side polish fixes an empty marketplace. The live class flow is the harder of the two, because scheduling has real consequences and an instructor who misconfigures a time zone strands a cohort.

## Cross-cutting surfaces

Media playback, Google OAuth, and real-time chat, plus responsiveness work across the modules I owned. OAuth and payments are the two places where a bug does not degrade the experience, it ends the session, so both got more testing time than their line count suggests.