LMS App Starter · Industry version
Cohorts that move together, assignments with due dates, and a marking queue teachers can live with — a school LMS in code you own.
A school doesn't enroll learners one by one — it teaches 9B maths, third period, autumn term. This starter reshapes the LMS around the class: cohorts that move through material together, homework with deadlines and submissions, and a teacher view built for marking, all in a codebase your school controls.
01 · The problem
Self-paced platforms assume every learner walks alone, but a school's unit is the class. Twenty-eight students in 9B reach the algebra module the same week because the teacher took them there; releasing content is a teaching decision, not a drip schedule. An LMS without cohorts forces teachers to manage twenty-eight individual enrollments that were always really one.
Schoolwork is submitted, not just completed. An essay goes in by Friday, late ones are flagged, feedback comes back attached to the work, and a mark lands somewhere a report can find it. Consumer platforms have quizzes but no submission model — so homework retreats to email attachments, and the LMS becomes a video shelf.
The calendar is termly and the audience is triple. Courses run September to December, then reset with new cohorts; students see tasks, teachers see marking, and parents need a read-only line of sight onto both. A platform with one learner role and no notion of terms fits none of the three.
02 · Data model
Everything in the base LMS starter —
coursesmoduleslessonsenrollmentsquizzesinstructorscertificates— plus the entities this industry actually runs on:
| table | what it holds |
|---|---|
cohorts | A class group — students, teacher, subject, term — enrolled and progressed as one unit, the way schools actually work. |
assignments | Set work with instructions, due date, and points — attached to a lesson or module, issued to a whole cohort at once. |
submissions | Student work against an assignment — files or text, timestamped, with status from submitted through marked and returned. |
03 · Screens
Teachers release modules to the class when the class is ready — this week's content this week, next module locked until they've earned it. Progress views read per cohort, so 'where is 9B?' has one answer instead of twenty-eight.
Set work issues to the whole cohort with a deadline; submissions land in one queue sorted by status. A teacher marks straight down the list, feedback attaches to each piece of work, and late flags raise themselves. Sunday marking, minus the folder wrangling.
Courses belong to terms and roll over cleanly — the autumn course archives with its cohort's record intact, and the spring instance starts fresh with a new class. Nothing is deleted to make room, because history is what report season runs on.
04 · In practice
The teacher releases module four to 9B and attaches Friday's assignment. All twenty-eight students see the same new content and the same deadline; three who were away see exactly what they missed. One action, one class, no per-student administration.
Submissions arrive through the week; two land Saturday and flag late. The teacher works the queue Sunday — mark, comment, return — and by Monday every student has feedback on their own work, with scores recorded against the assignment for reports.
Autumn term closes. Its cohorts archive with complete records — content covered, work returned, marks earned — and spring cohorts spin up on the same courses with clean slates. The maths department's curriculum persists; the classes move through it.
Yes — release is per cohort and teacher-driven, not drip-scheduled. A module unlocks for the class when the teacher opens it, which can be gated on the previous module's quiz if you want the pacing enforced.
Assignments issue to a whole cohort with a due date; student submissions queue for the teacher, who marks and returns each with feedback. Late submissions are flagged automatically, and scores store against the assignment for reporting.
A read-only guardian view is a natural extension the schema supports — linked to specific students, showing progress, due work, and returned feedback without any ability to touch it. Whether to enable it is your school's call; it's your code.
No — this is teaching and learning. Official attendance, report cards, and guardian records of the administrative kind belong to the student information system starter; the two pair well, with the LMS feeding marks into the record-keeping side.
Dual7 App Starters
Cohorts that move together, assignments with due dates, and a marking queue teachers can live with — a school LMS in code you own. Describe your version to start — the output is a project you own.