Forem: Ben A.

RevenueSpot: A Reflection

Ben A. — Mon, 20 Oct 2025 19:58:20 +0000

RevenueSpot was an early project I worked on with the goal of learning a bit more about web scraping and how to use the Spotify API. I was also just genuinely curious about how much money each track on Spotify made.

Motivation

It was during the legendary Drake-Kendrick Lamar rap beef that a friend and I joked about how much more money these guys must be making off of this drama, what with people going to stream their music more. As these conversations often go, the topic of how much money they make came up and as musicians ourselves, how much money they must get per stream on Spotify. Given that Drake has songs with over 1 billion streams, I wanted to do the calculation.

The long-held understanding has been that Spotify pays artists less than pennies per stream. According to this music site, some forums, and others, the estimation that each stream is equivalent to $0.00028 in revenue. Spotify denies this (sort of). Either way, I have always looked for an excuse to use the Spotify API.

Initial Build

My first plan when building this out was to tap into the Spotify API to get play counts per track, then do some simple math to calculate the revenue. Strangely, the Spotify API doesn't tell you this. I sort of understand this given how play counts must be stored as a hyper-dynamic value, especially for artists like Drake. There were also no third party tools online that offered this info.

So, I whipped up a simple 'fetch track info' input element that grabbed whatever the Spotify API had to offer, and off I went into the wonderful world of web scraping.

Web Scraping

Believe it or not, I actually have a non-insignificant amount of professional experience using web scraping. One of the first tasks I had upon my first job out of Uni was helping the company QA team develop some Python scripts to test for the new design implementations.

At that time, the directive was to use Java with Selenium. It was fairly straight forward in 2018, before React and SPAs took over more of the web. The problem was that it was quite cumbersome (as is Java in general). Each element required practically a full 80-character line of code to drill down into. Innovation was needed.

One of the grand triumphs of my early career was making the decision to switch to Python and use BeautifulSoup instead to accomplish this task in front of me while also parameterizing the test suite for the QA team. They loved that. I loved that. Everyone was happy.

But now, years later, I was confronted with web scraping in the context of a new tech stack: a Node.js backend. Some research revealed that Puppeteer was the best library for this and off I went.

Success!

From there, it was relatively straight forward. Getting the play count element on the web page was pretty simple, just a matter of finding the right unique combination of HTML elements to drill into. A bit of configuration research was needed but that's exactly where our new AI Copilot friends can excel in. Ez.

The one tricky part was working around bot-tracking behaviors that browsers try to stomp out. I had to throw in some timeouts, tinker with the correct version of Chromium browser to use, and ensure I had the proper HTTP request configuration to prevent security measures from quickly shutting it down.

Sure enough, I had my solution! It was a bit slow, but it worked.

Failure!

Well, not sure if it's totally fair to say "failure" but I did toss this project up quickly into an AWS EC2 instance so I could move on to new, cooler (shinier) ideas.

The need for an EC2 instance was pressing as I needed a way for the scraper to boot up a headless chromium browser, let it run for anywhere between 15-90 seconds, and fetch the page data. I also just knew how to setup an EC2 instance from past experience.

In my deployment research, Copilot had pointed towards an AWS Elastic Beanstalk configuration to help save with costs when the project wasn't in use. I recognized that that was the best solution, it wasn't even particularly much more complicated... I just hadn't used it before and didn't feel like spending the time to learn. (guilty as charged).

This proved to be my downfall. What a surprise it was when I saw a $10 charge come across my credit card bill courtesy of AWS because of my RevenueSpot instance. I didn't budget for that!!

The failure part becomes a bit clearer when I mention that I let that go on for a couple months without digging too deep as I had moved interest to new projects and life situations. I also thought that perhaps I had just gotten some random hits of people using it and that it would go down the next month since I wasn't sharing it anywhere really.

I was wrong.

The End

It took a few months, but I finally have gotten around to shutting down the EC2 instance and the project as a whole. It's not a terribly useful tool, and I frankly don't feel that compelled or have enough free time to dig into how to make the deployment infra more cost efficient for this particular project.

That said, I did record a nice little video of it in action which you can see above or below.

Lessons Learned

I might be able to speak on the lessons learned from the technical implementations, or the infrastrcuture struggles, or even just how Spotify is doing as little as they can to pay artists. But truthfully, I think the lesson learned was how to go about these impulsive little project ideas in a more thorough manner.

Until next time,

TIL: Color Analysis

Ben A. — Thu, 18 Sep 2025 19:29:51 +0000

It's how these things go on teams, budgets, and companies large and small - you set out with one goal in mind and eventually lose sight due to the myriad of design, development & infrastructure decisions that come up in the meantime.

In this case, the team is just me, the budget is zero, and the project is a web app that's been roughly half-working for about three years. Meet "Synthesia".

There's no buzzy tagline or product sign-up sheet - it's just a project to see how to make (my) music more interactive. Users navigate to a page, are given a song, and asked to pick a color based on what they are feeling or hearing while listening.

an initial idea

After getting lost in the weeds of trying to make this a product for some reason, today I finally got to the fun part of doing a bit of color analysis.

At present, all tracks and their responses are saved to a supabase database with a 'colors' field existing as an array of hex code strings (i.e. ['fa012c', 'fffc43', 'c5e3a0', ...]). This has been the easiest to work with, easiest for users to understand, and a fairly quick solution.

However, the world of color science goes deep. I'm no Bob Ross, but even I understand how colors can typically be represented in values of hue, saturation, and lightness (or 'light'). These basic values are rooted in core art principles and have existed long before computer screens made them common vernacular. They refer to the pure base color like red or blue (hue), the purity and intensity of that said color (saturation), and the amount of blackness or whiteness within that color (lightness).

On computer applications from Photoshop to Figma to good ol' CSS, color can be defined by hex codes, hsl(), hsv(), and many more ways.

So, the challenge was to figure out what interesting info I could glean from a set of hex codes.

about the extent i can take hex codes (or is it?)

For the sake of time and simplicity, I began with a simple and easy translation of my hex codes into hsl (hue, saturation, light) format using chroma-js. This spat out a nice list of super long floating point numbers, but it gave me something to work with.

Next, concatenated each of the respective values into their own arrays, used a simple reduce() function to get a sum, and then extracted an average value for each. However, these were still just numerical values. In the online space, hue is interpreted as the degree at which the color sits on the color wheel while saturation and lightness are interpreted as percentages between 0% and 100%. A quick note that white, blacks, and grays will cause some wonkiness, so I took those out for now.

Some simple math led me a few nice values, just a step away from deriving something neat.

Finally, after a bit of finagling to figure out the correct syntax, I was able to define what is more-or-less the average color selected for this track!

There is hefty amount more that can be done to analyze just color values, but also an opportunity to do some statistical analysis to determine which tracks have an average color that follows closest to each of the individual selections. As you can see above, the derived color seems to be fairly reasonable. In the below track, however, the color appears to come out of nowhere.

I've always been drawn to statistics and took a few courses at uni but have never really gone too far into the realm of possibilities. Perhaps this is a good opportunity to collaborate with some statistically-minded friends.

In the next TIL iteration about this project, I hope to share a bit more on the technical considerations I made behind how to perform this computational analysis within my codestack.

For now, farewell.

-B

Turning Your "Braindumps" Into Trackable Tasks

Ben A. — Wed, 13 Aug 2025 20:09:40 +0000

*Do you spend more time organizing your to-do list than actually doing tasks? *
Do you often forget about important tasks?
Are you constantly recreating to-do lists to remember?

Well, then 🧠braindump💩 is for you!

👉🔗 https://brain.concourse.codes/

Whoa, whoa! Let's hold up a quick sec. I'll admit: this is definitely an MVP version and is also one of my first times working on a side project app that is seeing the light of day. I've been working on this project for several months now but have been struggling with knowing when to call it "MVP", but today I've decided that it's good enough.

Built using Next.js, React, my first try using TailwindCSS, and built on top of Supabase (I'm cheap), this project has mostly been built by hand as an learning opportunity. GitHub Copilot has helped me throughout, but I've been trying to improve my foundational skills here first and foremost. It also means that there may be some rough edges.

The premise of the app is simple - if you ever find it helpful to just raw-dump all your thoughts of to-do lists, tasks, thoughts, ideas, and random tidbits, then the goal of this app is to turn that raw list into tasks that can be categorized and prioritized. In this sense, it's no different than your run-of-the-mill task tracking application except that instead of inputting new tasks each time, you are dropping all your thoughts into a blank textbox.

Everyone has their own preferences but as someone with ADHD, I sometimes find any amount of pre-built structure around my braindumps to be cumbersome & distracting. Sometimes I don't want to fiddle with the neat (& helpful) features of to-do apps, I just want to drop everything in then sort it out later. The simplicity here is why most braindumps take place on paper - which I still find helpful.

The eventual goal is to build a scoring system around the tasks such that the app will tell you when a certain item has appeared a number of times without being completed. Perhaps it should be moved to the backlog if it isn't important, or maybe you ought to just get it finished.

This post is a bit sporadic & incomplete; I've just had enough of this "half-finished" state and wanted to do something to mark it as an official "MVP". Thus, keeping this writing within 10 minutes so I can focus on the actual work - have at it.

Giving myself a pat on the back and hoping for more good things to come!

✌️ Peace!

-Ben