BetaTestSongs.com

A fullstack web app used for EDM producers to get feedback on their songs.

What is BetaTestSongs.com

BetaTestSongs.com is for EDM producers. It's a tool to help solve the problem of getting unbiased feedback for WIP (work in progress) songs. It does this by creating a marketplace where producers can anonymously submit and review songs.

You can check out the code here.

Objective

Create something with as little work as possible that still helps people (i.e. build an MVP).

Even with this goal, throughout the course of this project I caught myself over engineering. I will go more into this later in the article.

Core Functionality

Domain Concepts

Song: a song that an artist wants feedback for.

Review: feedback given to a song.

Review Queue: a FIFO queue of songs waiting to be reviewed.

Review Started: a user has started a review and now "owns" that song for an hour. If the review is not completed it goes back to the review queue with top priority.

Review Finished: feedback has been submitted.

Access Patterns

Users can:

  • submit a link to a song
  • start a review, which will fetch the oldest song in the review queue
  • submit a review, which will trigger a notification email to the user that requested the review
  • see a submitted review for a song

Architecture

The web app is hosted with AWS using the following services: s3, CloudFront, ECS, EC2, ECR, RDS, & SES.

Here is a high level diagram of the cloud infrastructure that makes up BetaTestSongs.com.

Naturally as a web app, there are two distinct parts: the backend and frontend.

Frontend Tech

  • Vite
  • React
  • Tailwind CSS

Backend Tech

  • Containers
  • NestJS
  • Postgres
  • Terraform
  • Mixpanel (analytics)

The Database

Why SQL?

The primary reason I opted for SQL was for extendability. Features such as multiple reviews per song and selecting a random song would work better in a relational database.

Schema

The schema is pretty straight forward and handles our access patterns well.

Things That Reduced Time and Development Effort

  • Used a template and React components from Tailwind CSS.
    • Using a template and ready made React components helps so much with not messing around with design and responsiveness.
  • Opted out of user authentication.
    • By avoiding authentication I'm not only getting rid of an extra hurdle for users, I'm also saving myself from the complexity that comes with it.
  • Deployed directly from my machine (as opposed to using GitHub Actions).
    • This was the first time I did this. Instead of building out Github Actions and managing secrets, I just ran deployments directly from my machine.
  • Opted to use links instead of files.
    • Instead of managing file uploads, storage, and fetching, users just submitted SoundCloud links to their songs.

Wins

There were a few solved challenges that are useful and applicable to other projects.

Such as:

  • Prisma migrations for an RDS instance in a private subnet (Check out my post about it here)
  • Doing 0 downtime deploys with a single (free) t3.micro EC2 instance (Check out my post about it here)
  • Prevented users from viewing their own song submissions despite there being no login / accounts
  • Using Mixpanel to track page landings and first time visits

Mistakes

Recall that my primary goal with this project was to help users.

Over Engineering

The mistake that stood out was the one I was originally trying to avoid: over engineering. I caught myself spending time setting up cloudwatch alerts to enable scaling the application layer. I shouldn't have bothered with this until I actually needed it (i.e. when I had users). I also spent too much time setting up my infrastructure and deployments using IaC when I didn't need to.

All of this engineering effort is great when there is users, but if there is none it's a waste.

What I should have been focused on is creating a bare bones PoC (Proof of Concept). Something just good enough that I can show potential users and get feedback to see if I'm even solving a problem.

Technical Mistakes

I accidentally deployed a version of my site that had an api route hardcoded to localhost. In other words I had localhost hardcoded in the actual webpage itself. When I visited the site through my browser Google really did not like this. It blacklisted my site and warned users not to visit. I had to submit a request for them to review that the site is now safe. This was a really costly mistake and one I will not make again — use relative paths.

Takeaways

  1. Establish Product Market Fit above all else. If I want users, then users need to want the product.
  2. Just use Vercel. It's all you need for spinning up a web app quickly.
    • It's so easy to get up and running with a web app that has good performance, decent extendability, automated deploys, etc.
    • The best part, it even comes with a backend where you can store secrets and do any necessary server application logic.