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.

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

One Year Ago

June 14th, 2025: I was on an airplane, flying to Georgia to visit family. I'd been told over and over for the previous six months that mid-level managers were about to be decimated at Amazon. The problem was, the definition of a middle manager was fairly broad at Amazon. Which layer would see the cuts? Senior managers? Directors? VPs? I wasn't worried at first. I was a line manager and I loved my job. Or at least that's what I told myself at the time.

Somewhere around the week that I was traveling to Georgia, I realized something about the narrative on the upcoming middle-manager bloodbath: the middle-managers were in charge of handling the layoffs. Andy Jassy wasn't going to hand pick every layoff at Amazon. Suddenly, my 9 year job at Amazon felt tenuous at best. I started to realize that my time there was coming to an end, and I was fairly convinced that the industry was going to contract by 10% to 30%, in terms of job availability. So, while I was stuck on that flight, I revisited an idea that I had back in 2011.

Business ideas are all about solving problems for customers. I had a problem, and I was confident that most of the first world had the same problem. Back in 2011, I spiked up a rough Android app and put it on the Play Store for a few days, only to pull it when I decided that some big tech company would wipe me out if I tried to pursue the app in any real way. In my mind it was inevitable. But, years passed, and while the big tech companies took a stab at the problem, all of their solutions were coated in the oily residue of advertisements and data brokerage. I was the product, not the customer.

So, on that flight, I started sketching out high level diagrams of what I would build if I had the time and resources to do so. It would have to be "serverless". I couldn't afford to run hosts 24/7 until I had enough revenue to justify it. But, that also meant that cold start time had to be as low as possible. I needed a portable framework for developing the frontend so that I could have native apps for each platform. I started thinking about feasibility.

Money

The key feasibility question was money. Would I try to get funding? Could I bootstrap it? I'd been setting aside about half my total compensation each year for retirement/emergencies. The world had just changed. I didn't need to hire anyone. I could conceivably fund, design, build, and market my app with only the help of the various large language models. I was convinced that we were about to see a Cambrian explosion of independent developers and I wanted to get in ahead of the curve.

At the time, I wasn't convinced that I would take on the project. It was just an idea, noodling in the back of my mind whenever I wasn't busy with something else. But, the more I thought about it, the more convinced that I was that I needed to do something. I was suddenly confident that I was on the chopping block.

It took about 6 months, but my fear eventually turned into reality. A flood of layoffs, for colleagues who had been at Amazon longer than 7 years, filled my LinkedIn feed starting in November, 2025. The reason that so many tenured Amazon employees were being shown the door seemed obvious, but would become blatant on February 6th, when Andy Jassy shared Amazon's $200B AI investment plan. I joined them in February of 2026. I was sent an email notifying me of my layoff by the very notification system that I had helped build.

Because of my time at Amazon, I received a fairly sizable separation package. Between that and my savings, I made a decision. It was time to go all in on building my own software company and I was going to bootstrap it without investment.

What's Next?

I intend to use this publication to tell you about the ups and downs of my journey. I'm one year in now and I'm more convinced than ever that we're heading into another market crash that will wipe out demand for developers right at the moment that AI becomes transformative in the industry. Does that mean less software? No. It just means that you and I get to create that software on our own. The barrier to entry to building your own software company is at an all time low.

Get your severance; go build something amazing.

In the next few weeks, I intend to continue writing articles about my journey as a solopreneur. Here's a rough idea of the topics:

• Phase 1 — Launcher Prototype (Jul 2025)

• Phase 2 — Backend & Infrastructure (Aug 2025)

• Phase 3 — Rebrand & Real Infrastructure/Auth (Sep 2025)

• Phase 4 — TV UI System & Media Features (Oct 2025)

• Phase 5 — Layered Architecture & Riverpod (Nov 2025 – Feb 2026)

• Phase 6 — Cross-platform & Config-driven UI (Mar – Apr 2026)

• Phase 7 — Monetization, Observability, & Compliance (May – Jun 2026)

• Phase 8 — tvOS, Web Launch, Attribution, & Local Media (Jun – Jul 2026)

I also want to talk about some of the tools that I've built and the lessons I've learned along the way:

• Rust Based Static Analysis Tool

• Guidance MCP Server

• Naming a Company

• Where to Incorporate

• What Resources Do I Need and When Do I Need Them?

• Reducing Cold Start Times to Less Than 3 Seconds

• Using Flutter on tvOS Devices

I'm sure that more topics will come to mind. Who knows? Maybe I'll actually write an article for each of these.