TEC Planner
A retired experiment in degree planning, with prerequisites, completed courses and term-by-term workload. I no longer needed it.
TEC Planner explored a practical question for students at Tecnológico de Monterrey: how do the courses still needed for a degree fit into the coming semesters? Choose a programme, mark completed courses and set workload limits, then compare a faster path with a more balanced schedule.
I built the React planning interface, course-data parser and scheduling logic. The prototype modelled prerequisites, seasonal availability, credit limits and combined programmes, with a PDF export path. I retired it because I no longer needed the tool.
Highlights
- Completed courses and combined programmes
- Prerequisites, seasons and credit limits
- Fastest or balanced plans with PDF export
In action
A course list is only the beginning
A degree's published course list tells you what exists. Planning the next few years asks a different question: what can you take next, and what will that choice unlock? TEC Planner turns that problem into a sequence of visible decisions, beginning with the programme and the courses already completed.
The setup supports a single programme or a combination of two. Shared course codes are merged so the combined view does not count the same course twice. Students can plan every remaining course or select a smaller subset, which is useful when the immediate question is the next stretch of study rather than the whole degree.
Read the structure behind the catalogue
The backend reads programme information from the university's SAMP catalogue. Two HTML views provide complementary details: course areas include names, credits, prerequisites and equivalences, while the period view identifies a course's place and active teaching periods. The parser joins those records by course code into a consistent data model.
That translation matters because the planner needs more than labels. It needs to know which courses depend on each other and how credits occupy the three periods within a semester. The source also maps semester parity to seasonal availability, an assumption that belongs to this model and should be checked against current university information.
Balance speed against workload
The scheduling engine builds a dependency graph and identifies courses that unlock later work. It combines that ordering with semester and period credit limits, completed courses, and optional summer and winter terms. Fastest mode looks for an earlier finish; balanced mode lets the student choose a target length and spread the remaining workload.
Computation runs in a browser worker so changing the plan does not block the interface. Courses the model cannot place remain visible with reasons such as an unmet prerequisite, unavailable season, credit limit or circular dependency. A useful planner has to explain the gaps as well as show the successful placements.
Take the plan away
The result presents semester cards, credits and teaching periods alongside the estimated finishing point. A PDF export records the proposed schedule, remaining courses and warnings. Browser storage keeps setup choices and course selections so students can revisit the same planning exercise without starting from an empty form.
This was a personal planning experiment, and I retired it because I no longer needed it. Its export identifies itself as unofficial. The preserved code shows the attempt to turn awkward source data and interdependent rules into a plan a reader could inspect and adjust.