Triage

Inspiration

I started building Triage Study Planner around one question: What if students don't need another planner that fills their calendar, but one that tells them whether their plan is actually possible?

Traditional planners can help organize tasks, but a schedule may look perfectly organized while still being impossible to complete before important deadlines. When students fall behind, they often face an even harder question: what should they protect, what can they reduce, and what should they postpone?

I wanted to build a planner that treats limited time as a real constraint rather than an assumption.

What It Does

Triage Study Planner checks the reality of a student's workload before presenting a plan.

Instead of simply comparing total work with total available time, it evaluates whether enough capacity exists before each deadline. This helps reveal situations where a student has enough time overall but cannot finish an earlier assignment on time.

When a plan is infeasible, the application uses three clear decisions:

Protect: Keep the most important tasks safe.
Reduce: Shorten flexible tasks when the rules allow it.
Defer: Postpone lower-priority work when necessary.

The planner also includes a recovery workflow for when life does not follow the original schedule, helping students reconsider their remaining work instead of pretending nothing has changed.

How I Built It

I built the project as a client-side web application using HTML, CSS, and JavaScript.

Its core is a deterministic planning engine: the same valid inputs should produce the same decisions, without depending on a runtime AI service or an external planning API. This makes the reasoning more predictable and easier to inspect.

The application evaluates workload, deadlines, available capacity, and task importance to produce its decisions. It also includes task management, planning views, scenario simulation, recovery tools, and browser-based persistence so students can continue working with their plans.

I focused on keeping the planning logic separate from the user interface, making it easier to reason about the rules and test important edge cases.

Challenges I Faced

One of the biggest challenges was distinguishing between a plan that looks feasible in total and one that is feasible at every deadline. Extra capacity later in the week cannot solve an assignment that is already due tomorrow.

Another challenge was making the decisions understandable. A planner should not simply label a schedule as impossible; it should help students understand the shortage and make sensible trade-offs without sacrificing their most important work.

I also had to consider what happens after the plan is created. Tasks change, estimates are imperfect, and students fall behind. Recovery, task progress, saved data, and repeated replanning all introduce situations that require careful handling.

These challenges pushed me to think beyond the happy path and pay attention to edge cases, consistency, and the reliability of the application.

What I Learned

Building Triage Study Planner taught me to treat feasibility as a fundamental product requirement, not just a feature added to a calendar.

I learned how important it is to translate a real-world problem into explicit rules, make those rules explainable, and test situations where assumptions break down.

The central idea behind the project is simple: a useful study plan should not just tell students what to do. It should tell them the truth about what is possible, protect what matters most, and help them recover when reality changes.