It’s been a busy week.

Spun up multiple services, refactored a lot of code, and built a website for a new client.

Lots to cover.

Topics for this week:

• Unstuck

• YouTube Stats

• New Client Site

• “Free” Video

• AI Gaming

Unstuck

Last week I outlined a series of services I needed to add to Wave to check the boxes for a feature complete release, and with some crunch-time this week, I have all of them working in a production capacity, but not quite completely integrated into the app yet.

In the back of my mind, I was nervous to create new services in AWS because I’ve run into trouble in the past, specifically when I was working on hypebid.

I spent a few days troubleshooting the process to deploy a Docker image to AWS Lightsail at the time.

This time I planned to use AWS App Runner instead, which I think is a slightly less streamlined Lightsail (and ultimately App Runner and Lightsail are both wrappers for AWS EC2).

Unfortunately I was right to be nervous this time, too.

I clearly didn’t properly document the issue from last time because it took a full evening to finally find the same bug as last time, but luckily this problem’s half life was considerably shorter at a few hours rather than a few days.

The process itself really isn’t so bad:

• Build a working Docker image

• Setup an AWS ECR (Elastic Container Registry) to store the Docker image

• Push the Docker image to ECR

• Create an app in AWS App Runner using the image from ECR

• Add Environment Variables

• Run the app

I got the containerized version of the push notification service working in a Docker image, but when I tried to run it in App Runner, I wasn’t having much luck.

The App Runner logs were no help, the only offer was that the health check failed.

This meant that my notification service wasn’t even starting.

Only Amazon’s code was running, not mine.

After many conversations with different AIs, sending in screenshots and files of all the configuration I could come up with for context into what I was missing, I ultimately spotted a recommendation in a Perplexity result that I immediately knew was the answer.

I invested in a MacBook M3 last year as proper portable work machine, and so far it has proven one of the best investments I could have made, I use it all the time.

But one particular feature of the new proprietary Apple M series processors is that they are ARM chips, not x86 chips.

Docker then builds images on a MacBook M series as ARM, and AWS pulls that Docker image, not knowing what to do with it since it’s expecting x86, not ARM.

So I end up with logs in AWS that tell me nothing useful except “it didn’t work".

Kind of amazing that AWS doesn’t log a warning for “expected x86 architecture” somewhere, but also kind of amazing that I’ve fallen into this trap twice.

Once I used the Docker command to build for amd64 and not ARM, my new service started right up in App Runner, rather than failing for 10 minutes with no explicit clues.

It took 2 separate lessons, but now I am unstuck.

Following the successful deployment of the notification service, I’ve also deployed a message service, compression service, and moderation service which all worked first try.

As a future warning to all devs, be careful if building Docker images on Apple silicon - always use buildx.

YouTube Stats

It’s still wild to see the steady slow growth of this neglected YouTube channel.

Looking forward to spamming regular uploads to it very soon, but it’s chugging along nicely in the meantime.

The term “n8n” is trending down in search volume (down from 4 million to 3.22 million) which is still insane, and a key piece to this passive growth.

Can’t help but feel the need to capitalize while there’s still an unbelievable search volume and a comparably low level of competition to fulfill the demand.

Maybe next week YouTube crunch time will replace app dev crunch time.

But here’s to slow growth, and the steady path to 1000 subscribers!

New Client Site

As if building out 4 new services for Wave and ignoring a YouTube channel weren’t enough, I also picked up a new client for divs.design - sort of.

New in the sense of a new project, but technically it’s a side hustle for an employee of an existing client.

Can’t beat business referrals.

Nothing too complicated initially, but I managed to get a prototype of what they wanted up and running for them this week to at least get the conversation started.

It’s much easier to be able to work with a visual than to try to talk about things in concepts and ideas.

We should be having a call next week to review the prototype more thoroughly, but I would imagine this should be live by the end of the month.

The divs portfolio slowly grows!

Going to need to update the website soon…

“Free” Video

As mentioned, once I was unstuck with the deployment process for Wave services, I learned a ton about the features I wanted to build, the next highest priority being an ffmpeg service to compress video.

Hosting and serving video is a surprisingly expensive and complex problem that’s easy to take for granted with the likes of YouTube, TikTok, and Instagram so readily bombarding everyone with videos all the time for free.

After a few discussions with o3 and Gemini Pro, I developed a straightforward enough system to mimic what those platforms do on a smaller scale.

To prepare for serving lots of video, my service stores the original video, then super compresses a shareable version.

Depending on the device, a 10 second video recorded on an iPhone at 1080p is about 18 MB.

The compression service uses ffmpeg to reformat the video down to about 616 KB, more than 20 times smaller, to save in costs for viewing the video.

Supabase allows for 250 GB of complimentary bandwidth (egress) per month and charges $.09 per GB after that, so they’ll let that 18 MB, 10 second video be viewed about 13,888 times for free, which sounds like a lot.

But say someone swipes through 10 of those 18 MB videos (thinking about how quickly you can swipe through videos on TikTok or Instagram and how 10 video views is basically nothing), there goes 180 MB of bandwidth for the month.

And that’s just for one user.

Assuming the app has at least 100 users doing that in one sitting, that’s now 18 GB of data bandwidth gone.

With aggressively optimistic growth, say 1000 users, all swiping through 10 videos in a row, doomscrolling without even really watching any of those videos, that’s 180 GB in 10 seconds.

And that’s just 10 seconds of boredom on a Friday night.

Supabase gives you 250 GB to work with for the entire month, and at that rate, it’s burned within the first hour of the month.

Continue with that rate and Supabases overage charges, and you can reasonably expect to pay at a minimum, $479.70 for the month to handle 10 video swipes per day for 1000 users.

But, with properly compressed video, 616 KB rather than 18 MB, 10 swipes of video is now 6 MB instead of 180 MB.

1000 users swiping through 10 videos becomes 6 GB instead of 180 GB.

At that rate, 1000 users could swipe through 10 videos every day, and it would only use about 186 GB total, well under the 250 GB provided by Supabase for free.

So this is why it’s worth the time and effort setting up a compression service to compress users’ videos down from the original format.

Potentially saving $479 per month at a minimum.

It’s a wonder any app offers free video at all.

Egress costs are expensive.

AI Gaming

Can’t wrap up without an update on the current standings of the AI leaderboard.

Only a subtle change this week.

A newer version of Gemini Pro replaced the old one (gemini-2.5-pro-preview-05-06 vs gemini-2.5-pro-preview-03-25) as number one on the leaderboard.

Bit of a controversy there because Google straight up replaced it rather than offering a new one while still offering the old one.

That’s typically not best developer practice so I’m not sure if Google had a good reason for that or not.

With enough backlash I’m sure they’ll make the old version also available again.

But that didn’t stop Gemini Pro from beating Pokemon Blue this week.

It sounds like the developer running the project had to provide a number of tools to help Gemini beat the game so it technically didn’t just figure it out on it’s own, but still impressive none-the-less.

It’s also interesting to consider both sides of the victory.

An all-knowing AI model can still struggle with a “kids game” both showing how complex games can be, but also how much further AI models have to go before they’re able to fully reason through complex scenarios.

Just a little food for thought for the weekend.

Congrats on beating a classic, Gemini Pro!

And that’s it for this week! Another newsletter all about the future: streaming, AI, crypto and divs.

Those are the links that stuck with me throughout the week and a glimpse into what I personally worked on.

If you want to start a newsletter like this on beehiiv and support me in the process, here’s my referral link: https://www.beehiiv.com/?via=jay-peters. Otherwise, let me know what you think at @jaypetersdotdev or email [email protected], I’d love to hear your feedback. Thanks for reading!