Osvitly

What was technically hard

A gradebook has to be honest about a term that is only half finished. The naive version divides by everything planned, so a pupil three weeks into a course reads as failing, and a parent who sees that number acts on it. Totals here accumulate only the items a pupil actually has a grade for; attendance is measured against lessons that were actually marked, so an unrecorded lesson never counts against anyone and an excused absence never punishes. The other half was making it fast: every gradebook view assembles from a fixed number of queries no matter how many pupils are in the class, and a test guards that count so a later change cannot quietly reintroduce a per-pupil lookup.

How it's built

Django 5.2 and DRF on PostgreSQL, Celery with Redis for asynchronous work, JWT for the SPA and API keys for machine access. React 19 with shadcn/ui and Tailwind on the front end, an Astro landing site, Stripe for subscriptions, and an MCP server so lesson content can be drafted with an AI assistant against the school's own curriculum.

One decision we made, and why

Grades are always stored as decimal points, and the grading scale is a display preset rather than a storage format. Ukraine's 12-point scale is what most schools here expect to see, and the obvious implementation stores twelve-point values directly — until a class switches scale and every historical grade has to be migrated, or two classes in one school need to display differently from the same data. Converting on read costs a translation on every view; it buys a gradebook where changing how a grade looks never changes what it is.