Prototyping

Note: this post is part of a series: Bitflinger TV Development.

First Designs

July 4th, 2025: I was in the living area of a cabin just outside of the downtown area of Glacier, WA. The room was two stories, taller than it was wide, with warm, rough-hewn wood for walls. Despite the cabin walls, the facilities were upscale as cabins go: large windows, heat, electricity, and running water; even a hot tub that we never used. My wife and I decided to pack up the dogs and rent the cabin in an effort to avoid the warzone that our neighborhood becomes every year on the 4th of July. We spent most of the day taking long walks with our dogs. After everyone else had retired for the night, I found myself sketching ideas for my app in an e-ink notebook. This was the first opportunity that I'd had to devote to the idea since returning from Georgia a week or so prior.

The Problem

At the time, I was thinking about a first-world problem that I'd had since 2011. Namely, how to browse shows/movies across the various streaming apps and maintain a watchlist in a single interface, without dealing with advertising. That last requirement was the kicker. Google TV and Fire TV each had browsable, leanback interfaces, designed to direct their customers to titles across the various streaming apps through a browsable interface. However, both Google and Amazon had their finger on the scale when suggesting which streaming app to select. The, arguably more successful, Google TV platform would push their customers toward buying titles in the somewhat unsuccessful Google Play Store video section; while the less successful Amazon Fire TV platform would push their customers toward buying titles in, the arguably more successful, Prime Video streaming app.

Oh, and they both riddled their respective user interfaces with ads. They had overt advertisements for pizza, tax preparation, and cars as hero images/videos near the top of the screen. But, even more insidiously, they prominently showed titles promoted by various streaming services, ensuring that one could never fully trust their recommendations. They used (and I presume that they always will use) customer watch history to improve advertisement targeting. So, as an example, you might start seeing gardening-related advertisements in your everyday life because you watched Zack Galifianakis' gardening show (which I hear is a real treat.)

Anyway, I digress. So, I was sitting in that Glacier, WA cabin, with a glass of wine, tapping a plastic stylus against my temple, wondering how I could build a replacement launcher for Google TV and/or Fire TV in the cheapest way possible. Ideally, I wanted to create a one time fee type of app. Something without hosted parts that would cost me a lot of money each month. I should clarify that I didn't want to build another app launcher for my TV. Those were a dime a dozen in the app stores. I would see a new one launched on Reddit every few days. Project Ivy was my favorite at the time because of the customization it allowed. These apps inevitably focused on removing the advertisements and bloat, but not browsing and discoverability in an aggregated UI. As far as I could tell, only the big tech companies had attempted a fully aggregated launcher. So, if I wanted to take that task head on, I needed a way to retrieve the metadata for my unified interface.

Time for Decisions

The big question was infrastructure. Could I get away with building the app that I wanted without servers? Maybe I could re-use someone else's existing free service? I'd used a few applications over the years that required an API key for a third party service, so the idea wasn't outlandish, even if I bristled at the idea of it. I've used several Spotify clients over the years that forced me to create an API key that I had to pass into their interface. Maybe I could get away with integrating with TMDB's API for metadata in a similar way? I toyed around with the idea of generating QR codes to make the process less infuriating. But, after a few days of digging, I decided that I would need multiple vendors to source the data that I needed. I even spiked it up and showed it to my wife to see how bad it would be. But, asking a customer to figure out how to generate an API key and get that API key on their TV, not once, but twice, was a non-starter. She barely looked at the demo before shaking her head and indicating that she would under no circumstance, ever jump through those hoops as a customer.

So, I went back to my original diagrams from that night in the cabin. I couldn't afford to run servers 24/7, especially not while I was prototyping. It would need to be serverless in the, function as a service, sense. But, a 20+ second cold start time was untenable. So, runtime/JVM-overhead languages were out; especially Java and the insanity of SnapStart. I needed something compiled that could cold start in less than 3 seconds reliably. I dialed in on Rust and Go as the most performant options, but I had never used either language. After a good bit of research, I decided that Rust would be the best choice for me. I'm really happy with that decision by the way. Of the potential, super painful, one-way doors, it was the one that I was most worried about. I'll talk about Rust at length in a later post, but I think that it's safe to say that Rust has changed my life.

Anyway, now I had my backend language. In the next article, I'll go over a few of the more important choices that I made in that first month. But, to whet your appetite a bit, here are a few giveaways ahead of time:

• Flutter/Dart for cross platform support (another decision that I'm happy about, although the deep nesting is super annoying at first)

• Kotlin for CDK and Gradle (on the fence about this one; not sad about it, but it bit me a few times)

• Python based Lambdas for database initialization and updates

• AWS for hosting (this just made sense, given my prior 9 years at Amazon)

• AWS Organizations for SSO and accounts dedicated to each service

We'll talk about all of these decisions in more detail in the next article, but in the first month, I established all of the languages that I would use to implement my app: Dart, Kotlin, Rust, and Python. That's it. I mean there are a few DSLs for configuration here and there, but I've tried to stick to 4 languages for writing logic. Okay, there's some Swift too. I don't really count it though, because there are only, like two files. Anyway, before I got started, I needed to learn Dart and Rust. More to come on that.