All projects

TuteeDex

A desktop app for private tutors to keep their students, guardians, subjects and fees in one place.

Code on GitHubUser guideDownload a release

Needs Java to run. It opens with sample data.

The TuteeDex window, with a list of student cards and a command box.
The main window, with sample data.
When
Aug to Nov 2026
Role
Team lead
Team
Five people
Made with
Java, JavaFX, Gradle, JUnit, GitHub Actions

What it is

TuteeDex is for independent private tutors. It keeps student details, parent or guardian contacts, subjects and fee tracking in one place. You type commands, and the window shows you the result.

We made it as a team of five for CS2103T, the software engineering course at NUS, and we started from the course’s AddressBook codebase. It went through four releases, from v1.3 on 15 October to v1.6 on 3 November 2026.

My part

I was the team lead. In practice, that meant running our weekly meetings and agendas, deciding how pull requests get reviewed and merged, and coordinating the releases and two rounds of testing. By 1 November, I had reviewed 32 of my teammates’ pull requests and merged 20 of them as the assigned merger.

I also had my own features, which were importing students from a CSV file, reopening the app with your last list view, search, and notes. A lot of my own code was drafted with AI coding tools. I chose the features, tested each change and approved what went in.

What I learned

  • A rule does not really hold if the team had no say in it. Our review rule got better on the day two teammates pushed back on it.
  • Small and clear asks before a meeting work better than a long agenda.
  • It is okay to move a bug to the next release, as long as you write it down.

Decisions

These go from the first to the latest. For each one, what I saw and what I did about it.

  1. We could either make it for tuition centres or for tutors who work alone.

    We chose independent private tutors, so we could focus on one person's admin

  2. Five of us were about to start pushing to the same repository.

    I wrote down one git workflow for the team, from issue to branch to pull request

  3. Our commit messages kept slipping from the course convention, and we only noticed after merging.

    I set up an automated commit message check that blocks the merge

  4. Two teammates pointed out that fixing merge conflicts could change the code after it had already been reviewed.

    I changed my own rule. The author fixes feedback and conflicts, reviewers check again, then it merges

  5. Alpha testing was coming up and we had no shared way to collect bugs.

    I set up one bug sheet. We collected all the findings first, then split them evenly

  6. I found two bugs in a teammate's pull request close to a release.

    I logged them for the next version so the release could still go out on time

  7. After deleting a student, the list could jump back to showing everyone, and the row numbers shifted.

    A delete now keeps the current filter, and the saved view only clears when the filter changes

  8. If you made a typo in a command, it got saved into the address or notes field without any warning.

    Unknown prefixes are now rejected with a clear message