Timetable Management System — Automated Scheduling Engine

A university timetabling system built around a deterministic scheduling engine — greedy placement with most-constrained-first ordering and bounded backtracking, guaranteeing every generated entry satisfies all hard constraints.

Web2026Solo Engineer — Final Year Project

Code

Timetable Management System — Automated Scheduling Engine — Web project by Muhammad Sameer

Next.jsTypeScriptPostgreSQLPrismaConstraint SolvingScheduling

Case study

How this was built, in the order I'd walk someone through it.

01
Problem
Building a timetable by hand is a constraint satisfaction problem people solve with a spreadsheet and a lot of backtracking. Every course needs a teacher, a room and a slot; no teacher can be in two rooms at once, no room can host two classes at once, and teachers have their own availability windows. Change one thing late and the conflicts cascade.
02
Users
AdministratorTeacherStudent
03
Architecture
Next.js App Router over PostgreSQL via Prisma. The domain is modelled explicitly — Course, Teacher, Room, TimeSlot, TeacherCourse, TeacherAvailability, Timetable, ScheduleEntry and Conflict are all first-class tables — and the scheduling engine lives in its own module, isolated from all of it.
04
My responsibility
Built end to end as a final-year project.
05
One important feature
A scheduling engine with no I/O
The generator is a pure module: no database, no network, input in and plan out. That single constraint is what makes a scheduler testable — you can drive it with a fixture and assert on the plan, instead of standing up a database to find out whether it still places classes correctly.
06
How it works internally
Placement is greedy with most-constrained-first ordering: before each step the engine counts how many (slot, room) options each unplaced item still has and schedules the tightest one next, which sharply reduces how often it has to backtrack. Backtracking is bounded by a hard step ceiling so a pathological input degrades into a partial plan instead of hanging the request. Hard constraints — teacher availability, room and teacher double-booking — are checked in a separate conflicts module, and every entry the engine emits is guaranteed to satisfy them.

More projects

See all

Web

Advara — AI-Powered Social Commerce Platform

Web

NexShare — Full-Stack Social Sharing App

Web

Job Card — Automotive Service Workflow

Timetable Management System — Automated Scheduling Engine

Web2026Solo Engineer — Final Year Project

Code

Next.jsTypeScriptPostgreSQLPrismaConstraint SolvingScheduling

Case study

How this was built, in the order I'd walk someone through it.

Problem

Building a timetable by hand is a constraint satisfaction problem people solve with a spreadsheet and a lot of backtracking. Every course needs a teacher, a room and a slot; no teacher can be in two rooms at once, no room can host two classes at once, and teachers have their own availability windows. Change one thing late and the conflicts cascade.

Users

AdministratorTeacherStudent

Architecture

Next.js App Router over PostgreSQL via Prisma. The domain is modelled explicitly — Course, Teacher, Room, TimeSlot, TeacherCourse, TeacherAvailability, Timetable, ScheduleEntry and Conflict are all first-class tables — and the scheduling engine lives in its own module, isolated from all of it.

My responsibility

Built end to end as a final-year project.

One important feature

A scheduling engine with no I/O

The generator is a pure module: no database, no network, input in and plan out. That single constraint is what makes a scheduler testable — you can drive it with a fixture and assert on the plan, instead of standing up a database to find out whether it still places classes correctly.

How it works internally

Placement is greedy with most-constrained-first ordering: before each step the engine counts how many (slot, room) options each unplaced item still has and schedules the tightest one next, which sharply reduces how often it has to backtrack. Backtracking is bounded by a hard step ceiling so a pathological input degrades into a partial plan instead of hanging the request. Hard constraints — teacher availability, room and teacher double-booking — are checked in a separate conflicts module, and every entry the engine emits is guaranteed to satisfy them.