Disclaimer

This is a somewhat involved breakdown of my 2 and a 1/2 year technical project as the Automation chair for Album of the Week. We will get into the weeds a bit about the project in various ways so for a lighter summary, refer to my resume

Overview

Album of the Week (AotW) is a university affiliated club at Texas A&M University in College Station. We discuss a musical album every week and as of Fall 2025 we have 200+ members and roughly 50 DAU. In short we have 2 external services that run in tandem:

• the club website (React.js, Express.js, Google OAuth, REST)
• and it's discord bot (Javascript, Spotify API, Google Drive API)

as well as 2 behind the scenes ones:

• our host of digital ocean serverless functions (Typescript, Spotify API)
• and a PostgreSQL database

The service I developed for it ties deeply with the function of the club, so an explaination of it is in order.

Background

Every week, we have a genre that we aim to discuss (this is on a weekly rotation of different genres) and our members can each nominate an album that they want to talk about on Monday night. Then, after a day has passed every member can vote on the albums they want to talk about, and then finally the next day between the most voted 5-6 albums we randomly decide (weighted to the number of votes each album got) which album to discuss for the week.

Architecture / Technical Breakdown

tamuaotw.com

This website is a React.js & javascript frontend with a Express.js & Node.js back end. In the front end we handle basic club info (live event updates, about me, etc.) and mainly the album selection process (explained above in the Background section).

• Nomination for the album interfaces with Spotify's developer API so that users can either search their album on the website or paste a Spotify link directly nominate their album. They can then choose a favorite song (auto populated from Spotify), describe the album/their case for it to be voted, etc. all of this interfaces with the database to be stored.
• Voting then occurs, users can come to the site then select the allowable amount of albums to be voted (varys based on number of albums nominated) while browsing through them all: looking at descriptions written by the nominators, the listed genres, or while listening to the auto generated Spotify playlist that the Discord bot handles (more on that later).
• Then finally, we have the Album Release. Internally, PSQL logic ran our digital ocean service decides the album and then reflects that to our members. On the front end, we have a countdown to the release of the album for the week; the top 5-6 albums have a weighted random chance between them to be choosen so we decided to style it like a decision wheel (à la pickerwheel or wheelofnames)!

Discord bot

The discord server for AotW is our main form of communication. The bot handles timed announcements in the discord currently; it used to, however, handle almost all of our business logic (I plan to write a blog post soon about the ups and downs of that decision). The bot is written in javascript and interfaces heavily with Spotify api and Google drive api, and is directed by our digital ocean business logic now.

Digital Ocean serverless functions

DigitalOcean serverless functions are a cost effective way to crystalize most of the business logic in the cloud and make sure that it runs properly (hosting for the discord bot has historically had many issues). In addition to having a better uptime record than the discord bot, serverless functions have quicker deploy times/improved CD setup, more accomodating structure for future features, and of coruse a lack of interdependence on the discord bot.

PostgreSQL database

The database is pretty simple, there is storage for our events, discussions, members, etc. and data is populated daily by the digital ocean business logic. Schema design and general storage architecture for this wasn't terribly demanding or complex; the use case just isn't there for a very involved PSQL solution

Project Management / Soft Skill Growth

I've spent 2 and half years as a dev for Automation within AotW, and a year and a half of that as the chair (i.e. the lead). In terms of operations, my goals going in taking the position were to:

1. Iron out DevOps and give the team a reliable way of allocating engineering hours, roadmapping features, and resolving bugs.
2. Create CI/CD and testing tools so that we can reliably and quickly ship features.

To this end I implemented:

• An in-house task management spreadsheet, designed to have minimal overhead while cleanly communicating feature status, expectations, and current buildout and to give a single source of truth about the man hour allocation for any given period of time.
• A refactor of Git structure, eliminating vestigial master branch that created unnecessary concurrency debt; this was paired with GitHub CI/CD pipelines using GitHub Actions, both working to ensure readable Git trees.
• A streamlined onbaording process, resulting in 24% shorter time-to-productivity gap for new developers.
• A new interview process, honed in on collaborative project based development in-person that aimed to capture the ability of candidates to mesh into a team, lead/follow when needed, gather requirements, and thoughtfully use AI tools.

Overall my guideposts when it came to my time at AotW were to design features that focused on reliablity and maintainability. This includes changes to how development is orchestrated internally; the code relies on us to maintain it after all.

Summary

Automation work for AotW is a multiyear project that I've undertook that gave me experience in fullstack web development, technical project management, and much more. It's become a cornerstone of my journey as a software engineer and has shaped my views on how leadership, good code, and proper engineering is conducted. Reach out if you have any questions!