Learning Management System

Course platforms get hard in the middle: content has an order, enrolment has a state, and an assessment result has to mean something in the context of a specific learner's progress. Treating those as separate features produces a system that cannot answer basic questions.

The data model came first: courses contain ordered modules, enrolment links a learner to a course, and attempts link a result to both. Content delivery and assessment endpoints are queries over that model rather than special cases.

• 01Course and module structure with ordered content
• 02Content delivery scoped to enrolled learners
• 03Assessments with submissions and results
• 04Progress tracked per learner, per course

1. Model the curriculum, not the screens

   Course, module, lesson, enrolment and attempt are first-class entities, so ordering and access rules are enforced in one place.

2. Typed boundaries

   FastAPI's request and response schemas define the contract between backend and any client, which kept the API honest as features were added.

3. Progress as a derived fact

   Learner progress is computed from completed content and attempts instead of being stored as a mutable percentage.

The LMS is the project that made relational modelling click for me: most feature requests became queries once the entities and their relationships were right. It is used internally.