8 Months at HT Labs: What Building OTTPlay Actually Taught Me
In August 2024, I was a B.Tech CS student who could write code but had never touched a real production codebase. By April 2026, I had helped migrate an entire frontend from Webpack v4 to v5, built features used by actual OTTPlay users, and sat in meetings where I slowly stopped thinking people were fighting — and started understanding how product thinking actually works.
First Month: Module Federation and Learning to Read Before You Write
My first task was building a prototype using Module Federation — which, if you haven't heard of it, is a Webpack feature that lets you split a large frontend into smaller, independently deployable pieces. For OTTPlay, this made a lot of sense. The codebase was large, the team was lean, and any update to the movies section shouldn't risk breaking the news section. Separate teams, separate deployments, separate concerns.
But before we wrote a line of code, we read. A lot. How do other streaming platforms structure this? What does the community say about monorepo vs multi-repo? Which architecture works better at our scale?
That discussion about monorepo vs multi-repo was my first real "engineering decision" moment. And the answer — as with most things in software — was: it depends. Depends on the team size, how tightly the modules interact, how fast you're shipping. There's no universally correct answer, and accepting that was actually freeing.
We started with advanced TypeScript, moved to Next.js, and eventually built a working prototype covering movies, shows, and news — complete with server-side rendering. SSR in Next.js sounds straightforward until you're debugging why your component hydrates differently on the server vs the client at 11pm. We figured it out. Slowly.
The CMS Chapter: Full Stack, Real Responsibility
After the prototype phase, I moved to OTTPlay's Content Management System as a full-stack developer — MERN stack. This felt like a different world.
The codebase was large, layered, and built over time by many people. Nobody hands you a map. You have to figure out: which file does what? Where do I add this feature? If I touch this, what else breaks?
Reading code became as important as writing it. Understanding why a file was structured a certain way, what the naming conventions meant, how data flowed from MongoDB through the API to the frontend — all of this before I could even begin contributing.
Gulam sir (senior frontend dev, coolest mentor I had) made this less overwhelming. He'd review my code, point at something and say "this works, but here's why we don't do it this way." He taught me how to write CSS that's scoped properly, how to build reusable components, how to think about a feature before building it. Bala sir on the backend side did the same for Elasticsearch, MongoDB, Redis, and server architecture. Two people who genuinely wanted you to understand, not just ship.
Our managers — Naba sir and Nishant sir — were the kind of people who made you feel like you could ask anything without it being a stupid question. That matters more than most people admit.
The Webpack Migration: The Hardest Thing I Did
Our biggest team task was migrating the entire codebase from Webpack v4 to v5, simultaneously moving to full TypeScript with strict typing. We did this in two sprints.
Here's what nobody tells you about migrations at this scale: you don't know what's broken until you change something. CSS broke in ways we couldn't immediately trace. Features stopped working that we hadn't even touched. The problem with a large, interconnected codebase is that updating one thing creates a ripple you didn't predict.
We spent days on things like: why is this CSS not applying? (Webpack v5 handles CSS modules differently.) Why is this component behaving differently in production? (A loader we used in v4 was deprecated.) Which TypeScript type is wrong here and where did it even come from?
But we shipped it. Bundle sizes went down. The codebase became more maintainable. And I now genuinely understand what "bundling" means — not just the concept, but the mechanics.
Tech I got real experience with across all of this: Elasticsearch, MongoDB, Redis, vector search, Redux, Material UI, Next.js, React, TypeScript, JavaScript, and CSS scoping.
The Meeting That Changed How I See Things
One afternoon I sat in on a meeting with my manager, the product manager, and leads from other teams. They were discussing a new feature requirement.
Honestly? From where I was sitting, it sounded like people were just disagreeing. Back and forth, pushing on different points. I thought: why is everyone fighting?
Then someone made a joke and everyone laughed, and the decision got made.
On the walk back I thought about it — they weren't fighting. They were each representing what their team needed, stress-testing the idea, making sure nothing got missed. That's just how cross-functional discussions work when everyone actually cares. I'd been reading it completely wrong.
That reframe — from "conflict" to "process" — changed how I show up in discussions now.
Where I'm Going
I'm not continuing at HT Labs, but I'm carrying everything forward. I'm currently growing from full-stack development into AI engineering — combining the frontend and backend foundations I built here with the AI layer that's becoming essential in every product.
One thing I'll tell every intern: the discomfort is the point. The week you spend debugging something you don't understand is worth more than a month of tutorials.
Let's connect