SMARTSCHED

Inspiration

Timetable scheduling in most colleges is still done by hand — an HOD or admin staring at a spreadsheet, manually juggling faculty availability, room capacity, lab requirements, and weekly workload caps, then redoing it all over again the moment one constraint changes. We wanted to see if we could take that entire manual process — org setup, faculty assignment, conflict-free scheduling, approval, and the day-to-day execution that follows (attendance, leave, substitutes) — and turn it into one coherent system instead of a spreadsheet and a prayer.

What it does

SmartSched is a full academic timetable management platform that covers the whole lifecycle, not just the scheduling step:

Org setup — Principals/Admins define the institution's structure: branches, blocks, academic years, regulations, curriculums, and rooms. Faculty & workload management — Faculty get assigned to subjects per class, with availability constraints and max weekly hour caps. Automated timetable generation — A scheduling engine allocates every subject's weekly hours across rooms and time slots, respecting faculty availability, room capacity, and load limits, prioritizing hard-to-place subjects (like labs) first. Approval workflow — Generated timetables move through DRAFT → SUBMITTED → APPROVED/REJECTED, so an HOD reviews and signs off before anything goes live. Day-to-day operations — Once approved, faculty log lectures as they happen, apply for leave, and the system handles substitute assignment automatically when a scheduled faculty member is out. Role-based dashboards — Faculty, HOD, and Principal each get a live view tailored to what they need to see. How we built it

The backend is a Spring Boot (Java 17) application structured package-by-feature — each domain (scheduler, faculty, leave, attendance, substitute, etc.) is a self-contained vertical slice with its own controller, DTOs, entities, mappers, repositories, and services, backed by MySQL/Hibernate.

The scheduling engine itself is the core of the project, split into three layers:

Algorithm layer — candidate generation, constraint checking, and scoring for room/faculty/subject allocation. Engine layer — builds each faculty's workload from their assignments, sorts it (labs and highest-remaining-hours first), and walks through slot-by-slot allocation using an in-memory occupancy matrix so nothing double-books. Optimizer layer — a post-generation pass that improves the draft timetable after the initial greedy allocation.

Authentication is stateless JWT with Spring Security enforcing role-based access (Principal, Admin, HOD, Faculty) across every endpoint.

Challenges we ran into Constraint satisfaction at scale — fitting every subject's required hours into a fixed weekly grid without collisions, while respecting faculty availability and room capacity simultaneously, is a genuinely hard combinatorial problem. A naive greedy allocator can paint itself into a corner where a subject simply has nowhere left to go. Avoiding repetitive output — an early version of the generator always picked the first valid slot, so re-running it produced nearly identical timetables. We fixed this by generating multiple valid candidates and picking randomly among the top few, so regeneration actually gives you variety. Keeping the workflow end-to-end — it was tempting to stop at "generate a timetable," but a real system also needs the approval loop and the operational layer (attendance, leave, substitutes) wired to the same data, which meant a lot more surface area than a typical hackathon scheduler demo. Getting the security model right across a large route surface — with ~20 feature modules, keeping role-based access rules consistent with every controller's actual route prefix is easy to get subtly wrong, and it's something we're still tightening up post-hackathon. Accomplishments that we're proud of A scheduling engine that actually runs the full allocation pipeline — workload building, constraint-aware candidate generation, conflict-free placement, and a post-pass optimizer — rather than a toy version that ignores real-world constraints. An end-to-end workflow that goes from org setup all the way through generation, HOD approval, and live day-to-day operation (lecture logging, attendance, leave, substitutes) — the whole loop actually works, not just the "generate" button. A clean, consistent architecture (package-by-feature, layered scheduler subsystem, DTO/entity separation) that made it possible to build this many modules without the codebase collapsing into spaghetti. What we learned Real scheduling problems need more than a greedy algorithm — we learned firsthand where pure greedy allocation breaks down (hard failures when no candidate fits) and why backtracking or constraint relaxation matters for production-grade schedulers. Role-based access control is easy to design in principle and easy to get wrong in practice once you have dozens of endpoints — a security model needs to be actively re-verified against the actual routes, not just written once and trusted. Building the "boring" operational layer (attendance, leave, substitutes) ended up being just as valuable as the scheduling algorithm itself, since a timetable that no one can act on day-to-day isn't actually useful. What's next for SmartSched Smarter allocation — move from pure greedy placement to backtracking or constraint-relaxation so the engine degrades gracefully (partial timetable + flagged conflicts) instead of failing the entire generation run when one subject can't be placed. Hardened security — finish auditing and locking down role-based access across every route (several endpoints currently fall through to a generic "any authenticated user" rule instead of proper role restrictions), and move secrets like the JWT key out of application.properties and into environment configuration. Student-facing features — currently the system is faculty/admin-facing only; a student view (their personal timetable, live lecture status) is a natural next step. Notifications — real-time alerts for substitute assignments, leave approvals, and timetable changes. Analytics — using the lecture-log and progress data already being captured to surface syllabus-completion tracking and faculty workload reports over a semester.