How I became a CTV Developer and helped speed up streaming apps

Introduction

When I joined Hypersolid as an intern in the web team, I definitely didn’t expect to end up optimizing streaming apps for devices with barely enough memory to run a browser. But that’s exactly what I do today.

I started here during my Communication & Multimedia Design studies. My long-term internship evolved into a graduation project, and after finishing my degree, I decided to stay. During that period, I got the opportunity to work with the Media Technology team. The mix of technical depth and the unique constraints of Connected TV development made moving in that direction feel like a natural next step. Looking back, that decision shaped my career more than I realized at the time.

After four years on the Media Technology team, Rick is now using his experience to mentor others

Building for the living room

At its core, Connected TV development is still web development. We use familiar technologies, but the devices we ship to are nothing like the machines we develop on, and nowhere near as powerful as a laptop or even a smartphone. Our apps run on TVs with limited CPU power, limited memory, and browser engines that behave differently depending on the model and operating system.

On top of that, users navigate with a remote control instead of a mouse. That changes how you think about focus, navigation, and interaction. Every decision has to be intentional, because you can’t rely on powerful hardware to smooth things over.

That’s what makes this work interesting. It forces you to build thoughtfully.

Growing into the role

When I started as a Junior, it was mostly about getting my hands dirty. I worked on internal projects first, then gradually moved into client applications. A lot of it was just building, testing on real devices, breaking things, fixing them, and learning along the way.

The team was still relatively small and evolving at the time, so most learning happened on live projects. You can study CTV development, but you only truly understand it when you’re debugging focus issues on a real TV or analyzing startup traces on lower-end hardware. The more projects you work on, the more you start to recognize patterns: what impacts startup time, what affects performance across devices, and how small architectural decisions can ripple through multiple apps.

That hands-on learning is something we now actively support through a structured onboarding challenge, giving new team members a practical introduction to TV development from day one.

Four years in, I approach things differently. I think more about trade-offs and long-term impact. I consider how a change will affect other platforms, not just the feature in front of me. And now I’m mentoring an intern myself, which is a nice reminder of where I started.

Making large streaming apps faster

Recently, I spent a significant amount of time improving the startup performance of one of our larger streaming platforms.

Startup is the most sensitive moment of a CTV app. Users open it and expect it to respond instantly. But behind the scenes, a lot happens during those first seconds: bundles load, logic initializes, players prepare, background processes spin up.

I wanted to understand exactly what was happening. So instead of jumping into random optimizations, I set up a repeatable test flow in our test lab. I defined how we would measure a cold start, what “usable” actually meant, and how we would test across both low-end and high-end devices. Every run followed the same structure, giving us a reliable baseline. From that point on, every change had to prove itself on real hardware.

The Hypersolid test lab houses all relevant models from leading manufacturers in the industry

The real issue: timing

Instead of discovering one obvious bottleneck, I found something subtler. The problem wasn’t a single heavy task blocking everything. It was accumulation. Over time, additional responsibilities had slowly moved into the startup phase. Extra logic executed immediately. Additional modules loaded upfront. Background processes kicked in earlier than they needed too. On modern hardware, that overhead is barely noticeable. On older SmartTV models from over eight years ago, with limited CPU and memory, it adds up fast. The interface might render on screen, but it doesn’t feel fully ready. The remote responds, just not instantly. Navigation works but feels slightly heavier than it should.

So I restructured the startup flow around one goal: make the app feel responsive as quickly as possible. That meant stripping the critical path down to the essentials. Only what’s needed for the first render stays in startup. Non-essential logic moves out. Background processes are deferred. Bundles are reduced and reorganized. Caching is improved so repeat launches don’t pay the same cost again.

After iterating and validating on real devices, the results were clear. By aggressively reducing what lived on the critical startup path, we didn’t just improve timing. We also significantly reduced how much code the app had to ship and parse upfront. The compressed bundle size dropped by roughly 60%, and on lower-end devices startup improved by three to four seconds.

On paper, that’s just a number. On a TV in someone’s living room, it’s a completely different experience.

Building systems, not quick fixes

What makes this even more rewarding is that the improvements didn’t stay confined to a single project. Our CTV apps are built on a shared core architecture. So when we improve startup performance or optimize caching strategies at that foundational level, those learnings can be applied consistently across platforms where relevant.

That doesn’t mean features are simply copied over. Each implementation is tailored to its own context. But strengthening the core architecture raises the bar everywhere. Improvements compound over time.

More importantly, the approach now sticks. Measure. Change. Validate. Repeat. That mindset prevents performance from becoming guesswork. It keeps us honest.

Why this field is worth it

Connected TV development is still frontend development, but with real constraints. You can’t ignore memory usage. You can’t ignore startup cost. You can’t rely on hardware to compensate for architectural decisions. And when you make something faster, you don’t just see it in a graph. You feel it immediately on the device in front of you.

That’s what I enjoy most: solving problems that directly improve how millions of people experience an app at home. You don’t need a dashboard to tell you it’s better. You can feel it the moment you press a button on the remote.

Interested in this kind of work?

If you’re a frontend developer who likes solving performance puzzles, working within real hardware constraints, and building apps used at scale by large audiences, Connected TV development might be exactly your kind of challenge.

And if that sounds interesting, I’d be happy to tell you more about what it’s like to work here.