UASC Project
A detailed look at how we transformed the admin process of the largest sports club on the University of Auckland campus (as of 2024) with a team of 13 developers.
Overview
TL;DR: I mentored and led 13+ student developers to create uasc.co.nz which automated the University of Auckland Snowsports Club’s booking, membership, and event management processes, replacing their manual Google Forms and payment systems with a mostly automated web application.
This application handles payments and signups for at least 700+ members per year
check out:
- GitHub repository for the project
- Live site for the project
What is UASC?
UASC (University of Auckland Snowsports Club) is/was (as of time of writing) is the largest sports club at the University of Auckland with 1000+ members in 2024. It was founded in 19661 and is a very busy club in terms of operations, with its fast-selling events and popular lodge location at the Whakapapa ski field2.
What was the project?
As the Technical Lead of the UASC project as part of WDCC3 in 2024, I, alongside a project manager was presented by the club executives with a problem:
How can we remove the manual processes of managing the club’s events, lodge bookings and member registrations, while also improving the user experience for our members?
The club had been using a combination of Google Forms and manual email communication to manage these aspects, which combined with the large membership base clearly showed a lot of room for improvement.
There had been a previous attempt at building a web application for the club, but it was far from functional:
Architecting the Solution
Problem Breakdown
As with any project, having a problem to solve is a good start, but to allow us to solve it, we need a deep dive into what the smaller components of the problem are. I needed to understand the three main stakeholders that would have major bearing in the solution:
- Guest (People who are viewing website without creating an account) - the potential new members
- Member (People who have created an account) - the current members who will want access to the club’s benefits
- Admins (Club executives) - the people who will be managing the club’s operations
From this we can see that the solution needed to be able to handle the following:
As a guest, I want to be able to:
- Be able to navigate to a rules and policies page so that I can view the clubs rules and policies
- Sign up as a member, so that I can be able to book lodges and access events
As a member, I want to be able to:
- View the club’s events and sign up them, so that I can participate in the club’s activities
- I want to be able to view available dates at the lodge, alongside the pricing as well as number of total spots and the remaining spots, so that I can make an informed decision planning my lodge stay
As an admin, I want to be able to:
- View the club’s members
- Configure all pricing (memberships, lodge stays)
- View the club’s events and manage them
- Check who’s staying at the lodge and when (while ensuring their safety with emergency contacts and dietary requirements)
- View the club’s finances and manage payments
Designer involvement
We were lucky enough to have a very competent designer on the team, who we were able to work together with to create designs that addressed the above user stories. The designs were created in Figma and were used as a reference for the frontend development. The designs were also used to create a style guide for the application, which ensured consistency across the application and made it easier for the frontend developers to implement the designs.
Solution Architecture
All of this points to a need for using a standard backend and frontend architecture, with all our operations being encapsulated in the backend. In order to deliver on an MVP (which we had 3 months to deliver) an architecture was determined with the following components
- Stripe: Could handle all payments and had high reliability Gith their API
- Firebase: Easy setup for authentication and user management, as well as a real-time database for all app-specific data
- Sanity.io: A headless CMS to manage the content of the website, such as events and lodge information with easy setup
- Nodemailer: A lightweight email library for sending emails to members, such as booking confirmations.
Building around these components is relatively framework-agnostic, so we could use any frontend/backend framework we wanted, with the choice being:
- React: suitable for team-based development due to component-based architecture
- note: I eventually made the decision to add next.js for static site generation to avoid having to do manual code-splitting and optimisations
- Express.js with TSOA: a good choice for building REST APIs with TypeScript support, simple to understand and has a
defined pattern that the team could follow
- This also allowed for integration with an OpenAPI typescript generator, which allowed us to generate types for the frontend and backend, ensuring type safety across the application
Here’s the initial architecture diagram that we implemented for the MVP, showing the main components that we required ( note that sanity was implemented later on, as for an MVP it was acceptable to have the content in the code):
Bonus: hosting and deployment
As a university club, we had to be realistic about our hosting and deployment options. We had a limited budget, so some compromises had to be made.
The most notable one was to avoid using anything server-based for the frontend and go with static site generation for 100% free hosting on cloudflare pages 4. This did mean that we had to be a bit more careful on what was fetched server-side.
Luckily, for the backend oracle offers a very generous free tier with their Oracle Cloud Free Tier5 which we can take advantage of two AMD compute instances.
Implementation
Over the course of the project, I mentored and led a team of 13+ student developers to implement the solution. All developers were expected to work on the full-stack, however obviously some had a stronger preference for frontend or backend development. A total of 328 tickets 6 were created for the project (albiet some were made after the MVP was completed)
Frequent meetings were held with the client to ensure that we were actually delivering what they wanted, and not what we thought they needed. This was a key part of the project, as it allowed us to iterate on the solution and make the necessary compromises to deliver the MVP on time.
Challenges
Some of the challenges that we faced during the project were:
- Time constraints: We had a limited time to deliver the MVP, which meant that we had to be careful about what we
could implement and what we had to leave out.
- An example of this is the CMS integration with Sanity.io
- Deployment was also initially done with firebase hosting, which was not ideal for a production application 7
- We also left the implementation of the event management system for later, as it was not a priority for the MVP.
- Team size: With a large team, it was difficult to ensure that everyone was on the same page and that we were not duplicating work. We had to be careful about how we structured the codebase - no architecture is perfect but more than that we needed to stick to a pattern and avoid premature refactoring over fear of tech debt.
- Differing skill levels: With a team of students, there were varying skill levels and experience with the technologies we were using. I had to ensure that everyone was able to contribute and learn, by identifying tickets that provided good learning opportunities for beginners and also ones that served as good growth opportunities for ” experts”.
- Developer motivation: As with any student project, motivation can be a challenge. I had to ensure that the team was motivated and engaged, by providing regular feedback and recognition for their work in weekly meetings, as well as ensuring that they were able to see the impact of their work on the project by involving everyone (where possible) in client meetings to show that there was a real face behind why we were building.
Outcomes
The project was a success, with the MVP being delivered on time and additional functionality being added following the MVP deadline. The club executives were very happy with the solution, and it has been in use since the start of the 2024 ski season. The application has been able to handle the large membership base and has improved the user experience for both members and admins. The club has been able to reduce the manual processes involved in managing the club’s events, lodge bookings and member registrations, and has been able to focus on running the best possible events and experience for their members!
Future Improvements
While currently the application is in a good state, there are still some improvements that can be made to the application, such as:
- Improving developer experience with the codebase
- Switching to a monorepo structure with Turborepo to allow for better code sharing and management
- Consolidating the infrastructure as IaC with Terraform to allow for easier management and deployment of the application
- Converting all content to be managed by Sanity.io, to allow for easier management of the content and to allow for more flexibility in the future
We’d be very happy to have any contributors/maintainers for the project, so if you’re interested in contributing, please feel free to have a look at the GitHub repository
Footnotes
-
https://auckland.campuslabs.com/engage/organization/uoa-snowsports-club ↩
-
It’s insane how you get unlimited bandwidth for static assets! ↩
-
Firebase hosting does not offer any protection against ddos or brute force attacks, which is a major security concern for a production application. ↩