Back to Portfolio
SCHOOL PROJECT
GradingDino Icon

GradingDino

I built GradingDino with a team of four for a BTS Cloud Computing project. It gives teachers a simpler way to grade their courses, while students can follow their progress. We delivered a working MVP and learned how planning and framework choice shape a product.

MVP
Last updated: 26/06/2026
Plain-English view, built for everyone Full technical detail
4
teammates, one codebase
3
roles: student, teacher, admin
1
command boots the whole stack
12+
user stories mapped before code

How a request flows

Container stack
Browser
any device
student · teacher · admin
HTTP form POST ⇄
docker compose · one host
Web container
port 8000
django 5.0 · python 3.11-slim · pico.css SSR
Database container
port 5432
postgresql 16 · named volume
One docker compose up boots both containers. Django waits for PostgreSQL's health check, applies migrations, then seeds the admin user automatically - no manual setup.

What it does

Teachers grade their courses

See and filter only their own courses, and enter grades with comments. Classes and enrollments are set up by the admin.

Students track their progress

Sign in to see grades per course with semester, school year and averages, and watch progress build over the year.

Everyone in their lane

Students, teachers and admins each get their own view - nobody sees more than they should.

Starts with one command

The whole app and its database boot together - it runs the same on any machine with Docker installed.

The Project

For my BTS Cloud Computing group project, I worked with three teammates on GradingDino, a grade management web app. We used project-management methods to turn teacher and student needs into a working MVP.

Team Structure & My Role

We worked as a team of four with clearly divided responsibilities:

  • My Role (Co-Developer): I built the application together with one teammate - Django models, views, templates, database design and Docker configuration.
  • Teammate (Development): Built the application with me, from the Django code to the database schema.
  • Two Teammates (Documentation): Handled the documentation - created personas, wrote all 12+ user stories with acceptance criteria, performed MoSCoW prioritization, and managed the MS Planner board.

Under the Hood

Five layers, two containers (web and database), all booted together by a single Compose file:

Presentation

Pico.cssSemantic HTML5Server-side renderingDjango Templates
  • Pico.css: a single-file framework that styles semantic HTML5 automatically - no build step, no learning curve, just write HTML.
  • Server-side rendering: Django renders every page and the browser posts back over a standard HTTP cycle, keeping all validation and CSRF protection on the server.

Application

Django 5.0Python 3.11-slimDjango ORMAdminFormsSessions
  • Batteries included: Django 5.0 on Python 3.11-slim shipped auth, forms, an ORM and an admin out of the box, so a small team could build features instead of plumbing.
  • Built-in admin: a customised Django admin manages users, subjects, classes and enrollments; the grading scales (20-point, 60-point and letter grades) come from seed data.
  • ORM models: classes, courses, enrollments and grades are plain Python models; committed migrations are applied automatically on startup.

Data

PostgreSQL 16ACIDConcurrent writesNamed volume
  • PostgreSQL 16: an ACID-compliant relational store that survives container restarts through a named Docker volume.
  • Concurrent writes: several teachers can grade at the same time without locking each other out - and the same engine scales to a production deployment.

Security

Argon2CSRFXSS escapingSQLi-safe ORMSession auth
  • Argon2 hashing: winner of the Password Hashing Competition (2015), created at the University of Luxembourg - memory-hard and resistant to GPU/ASIC cracking. A proud local choice.
  • Secure by default: Django ships CSRF tokens, template auto-escaping against XSS, and a parameterised ORM that blocks SQL injection.
  • Session auth + roles: Django's database-backed sessions plus role checks keep students, teachers and admins to their own views.

Orchestration

DockerDocker ComposeHealth checksAuto-migrationsPersistent volume
  • One command: docker compose up builds and starts the web and database containers together - identical on any machine.
  • Health-gated startup: the app waits for PostgreSQL to pass a health check, then runs migrations and seeds the admin user before serving traffic.
  • Persistent volume + live reload: database data survives restarts via one named volume, and the mounted code folder hot-reloads during development for fast iteration.

Why Django, and what it taught us

01

Before a line of code, we did the groundwork: personas, 12+ user stories with acceptance criteria, MoSCoW prioritisation, and an MS Planner board. Planning first gave us a clear picture of exactly what to build.

02

We compared Django, Flask and FastAPI. Django won on its "batteries included" philosophy - a built-in admin, auth, forms and ORM meant a small team could move fast without wiring everything from scratch.

03

The catch: Django wants things done its way. On a tight deadline we hadn't fully learned its conventions, so we spent time fighting the framework instead of building features. We still shipped a working MVP - and learned the "batteries" only pay off once you know how to use them.

Lessons Learned

Communication beats speed

Splitting work to move faster created silos. Next time, talking to each other gets the same priority as coding.

Framework choice matters

Django was great for prototyping but felt rigid when we needed flexibility. Research up front saves pain later.

Planning isn't optional

Personas and user stories felt slow at first, but they told us exactly what to build and what to skip.

Learn the tool first

Django's batteries only help once you know them. Under deadline pressure we fought the framework instead of using it.

A working MVP wins

It wasn't perfect, but it ran. Shipping something functional taught us more than endless planning could.