Case study · 2026
A web app for planning projects. You enter tasks with dates and dependencies, and the app draws the Gantt chart and works out which tasks, if they slip, move the delivery date.
To try it: user harriet, password demo. The data resets every six hours.
It started as an assignment I gave my students when I was teaching: tasks with two dates, a board and a Gantt chart, with dependencies as the last step. Then I rebuilt it on my own with a fuller stack: Spring Boot instead of Flask and PostgreSQL instead of MySQL.
The part I added is the critical path. Knowing that a task is blocked is easy. Knowing which tasks actually push back the delivery means looking at all the dependencies together: in the sample project it's 7 tasks out of 15.
Bars with a dark bottom edge are critical: if one slips by a day, so does the delivery. The striped tail after a bar shows how far that task can slip from where it's drawn before it moves anything else. Arrows go from a task to the one waiting for it.
In a task's panel you choose which tasks it waits for. The app doesn't allow a dependency that goes in a circle, won't let you close a task while the ones it waits for are unfinished, and tells you which task is in the way. Two people adding dependencies at the same moment can't create a loop either: additions to the same project are handled one at a time.
You can filter by status, priority and dates, and sort by date or title. The table and the chart read the same data, so they can't show different things. Bars in the chart can be dragged to change dates, and they snap back if the server refuses the change.
Two passes over the dependencies: forward for the earliest each task can start, backward for the latest that still doesn't move the delivery. Tasks with no gap between the two are critical. The model is deliberate: dependencies are finish-to-start, days are calendar days, and the forward pass ignores the planned start dates and schedules everything as early as possible, so "critical" means critical in an ideal replan, not in the plan as drawn. That leaves two different margins: the textbook total float, measured from a task's earliest possible start, and the striped tail on the chart, measured from where the bar actually sits. The tooltip shows both when they disagree.
Highlighting the chain that looks like the backbone by eye. In the sample project the chain that reads as central carries 9 days of float, and a different chain sets the delivery date. The critical path is still the longest run by duration; it just isn't always the one that looks longest on the chart.
A 403 would confirm that the project exists, and with ids in sequence, trying numbers would be enough to find other people's projects. The check is in the service layer, so it applies to every endpoint.
Putting the check in the controller: an endpoint added later could forget it.
Every task has a version number. The form sends it back when you save, and if someone else changed the task in the meantime, the save is refused instead of overwriting their change. The version is required, and the database checks it too, so no save can skip it.
Comparing the last modified date. It was the first version, and a test showed that after two saves in a row the same person was blocked as if they were someone else.