TutorHub — Building a School Management System as My Engineering Thesis
Adam SzczotkaFrom Excel Chaos to a Real System
My engineering thesis started with a real problem. A tutoring school with over 200 students was running everything in Excel — schedules, payments, attendance, parent communication. The owner was spending 10+ hours a week on tasks that should have taken minutes.
I proposed building a complete management system as my thesis project. Not a prototype, not a mockup — a production-ready platform that the school could actually use.
Why Django
The choice was deliberate. Some parents access the system from 5-year-old Android phones — a heavy SPA would not work. Django gives me server-rendered pages that load fast on any device, plus a built-in admin panel that the school owner could use immediately.
PostgreSQL was non-negotiable. Schedule slots use composite keys, and double-booking prevention needs database-level constraints, not just application logic. When two people book the same slot at the same time, the database rejects one — no race conditions.
The Architecture
The system grew to 17 Django apps, each handling a specific domain:
- Accounts — custom user model with 4 roles (Admin, Tutor, Student, Parent), email auth, GDPR-ready archiving
- Lessons — scheduling with FullCalendar, recurring lessons, room/tutor resource views, conflict detection
- Attendance — real-time marking (present/absent/late/excused), monthly reports with PDF export, low-attendance alerts
- Invoices — automated monthly billing via Celery Beat (runs on the 25th), overdue detection, payment reminders, PDF generation
- Messages — threaded conversations with group chat, file attachments, read receipts
- Cancellations — student-initiated requests, admin approval workflow, automatic makeup lesson creation with expiry
- Notifications — multi-channel (email, SMS, push, in-app) with quiet hours and per-user preferences
- Parent Portal — configurable access levels, invoice viewing, tutor messaging
Automation That Matters
The biggest impact came from background tasks powered by Celery and Redis:
- Invoices generate automatically on the 25th of each month — no manual work
- Overdue invoices are detected daily at 8 AM with automatic status updates
- Payment reminders go out 7 days before due date
- Lesson reminders notify students 24 hours before their scheduled lesson
- Makeup lessons expire automatically after 30 days if not scheduled
The school owner went from 10 hours of admin work per week to under 1 hour.
What I Learned
Building a system for real users is fundamentally different from academic projects. Users find edge cases you never imagined. They click things in orders you did not plan for. They need features you thought were obvious to be explained.
The audit trail (logging every CRUD operation with user, IP, and timestamp) was not in my original scope. The school owner asked for it after a parent disputed an attendance record. Now every change is traceable.
HTMX was a game-changer for the UI. Instead of building a full SPA, I could make Django templates reactive with minimal JavaScript. Attendance marking, lesson filtering, message sending — all work without page reloads, but the server still renders everything.
The Stack
- Django 5.1 + Python 3.11
- PostgreSQL 17 (database-level constraints)
- Redis 7 + Celery 5.4 (background tasks)
- HTMX + Tailwind CSS + DaisyUI (reactive UI)
- FullCalendar (scheduling)
- ReportLab + PyMuPDF (PDF reports)
- Docker Compose (deployment)
- Gunicorn + WhiteNoise (production serving)
Try It
A live demo is available at tutorhub.adamszczotka-pokaz.pl. The source code is on GitHub.
