How Teamer came to be

Teamer comes from seeing the same problem from two sides. As a student, I knew how much landing in the right group could affect my results. Later, tutoring a project-based CS course at UNSW where the group project carries most of the grade, I saw the other half of it: how the teams a course formed shaped both the learning and the outcomes for the students in them.

From either angle, the same gaps kept showing up. Teams were usually put together manually in a spreadsheet, or left to students to sort out among themselves. That worked well enough for most, but there were always a few students left at a disadvantage. Everyone in a course deserves a fair shot at a team that works. That is when the idea for Teamer was born.

I made it the focus of my final-year thesis. The work started with a proper literature review, months spent going through the research on how student teams form and what makes them work, and through the tools that already existed to see where they fell short. That reading, along with conversations with the people who run these courses and the students who sit in the teams, gave me a clear picture of what the best team formation tool would need to do. What I built took everything a course already knows about its students, from strengths and schedules to who they want to work with, and turned it into balanced teams a coordinator could review and trust.

I was not doing it alone. Professor Maurice Pagnucco, Deputy Dean (Education) in the UNSW Faculty of Engineering, supervised the work and has stayed involved with Teamer ever since. His experience in education shaped the direction early on, and his questions kept me honest about what teaching teams genuinely need. Much of how Teamer approaches fair team composition and the careful handling of student data came straight out of those conversations.

A prototype can only teach you so much. What truly shaped Teamer was putting it in front of the people it was built for. I sat down with coordinators and tutors to walk them through how Teamer forms teams, and asked them to be honest about what would hold up in their courses and what would not.

Their feedback showed me where the matching made sense and where it needed rethinking, and I reworked the formation flow around what they told me. A lot of what makes Teamer work well today traces back to those conversations, refining the original design rather than replacing it.

When it was finished, I did not want to put it down. I work as a software engineer, and for the past year and a half I have carried on developing Teamer in my own time, turning a rough prototype into a product I run properly. Everything runs in Sydney on Vercel and Supabase, so student data never leaves Australia.