Why I Built a Chrome Extension to Make YouTube Less Addictive (And What I Learned Shipping It)

I open YouTube with a clear intention.

Maybe I want to watch a tutorial, research a feature for a side project, or listen to something educational while working.

But somewhere between opening YouTube and finding the video I actually need, the algorithm takes over.

A recommended video appears. Then Shorts. Then comments. Then a rabbit hole I never asked for.

Thirty minutes later, I've forgotten why I opened YouTube.

YouTube Wasn't the Problem

The frustrating part is that I genuinely use YouTube for learning. Some of the most valuable programming knowledge I've picked up came from YouTube creators.

The problem wasn't the content. It was everything surrounding the content.

Most productivity extensions approach this one of two ways:

1. Block the site entirely
2. Limit access with a timer

Neither fit my situation. I watch tutorials almost every day. YouTube is a tool I need.

What I wanted was different:

Remove the addictive parts. Keep the useful parts.

That became the core idea behind YouTube Dopamine Detox.

What the Extension Does

The extension targets specific dopamine triggers — the design patterns that turn a 5-minute video into a 2-hour session.

Hide Shorts

Shorts are the biggest time sink. One leads to another. The extension removes every Shorts entry point on the page.

Hide the Home Feed

The homepage is optimized for engagement, not productivity. Removing it makes YouTube feel like a search engine instead of a social media feed.

Hide Related Videos

Even while watching a useful tutorial, the sidebar is constantly trying to redirect you. Removing it keeps focus on the original task.

Disable Autoplay

One video turning into ten is almost always caused by autoplay. Simple to implement, surprisingly effective.

Purpose Check

This is the feature I'm most proud of.

Before entering YouTube, the user is redirected to a lightweight page with one question:

"What are you planning to watch?"

The answer is stored locally. Then they continue.

The friction is intentional. Typing a purpose makes you stop and think. Sometimes that's enough to realize: "Actually, I don't need YouTube right now."

That moment alone is worth the feature.

Tech Stack

I structured it as a monorepo from the start:

youtube-dopamine-detox/
├── apps/
│   ├── extension/
│   └── web/
└── packages/
    └── shared/

Not because I needed the complexity, but because I knew I'd eventually want a landing page, shared types, and a privacy policy — all in one repo.

Fighting YouTube's SPA Architecture

Building the features was the easy part. Making them reliable was the real engineering challenge.

YouTube is a massive Single Page Application. My initial assumption — "select an element, hide it, done" — lasted about ten minutes.

When users navigate inside YouTube:

• URLs change without full page reloads
• Components re-render
• DOM elements get recreated from scratch

Features that worked on initial load would silently disappear after navigation.

To make the extension resilient, I ended up combining:

• Initial page processing on load
• URL change detection
• MutationObserver to catch DOM updates
• Re-applying rules after each navigation event

Most of the engineering effort went into resilience, not functionality. The features themselves are simple. Making them survive YouTube's rendering cycle was the actual problem.

No Backend, No Accounts — Intentionally

A lot of developers reach for auth, databases, and APIs by default. I skipped all of it.

Everything is stored locally using Chrome Storage. Here's why that was the right call for an MVP:

Faster development — No infrastructure to set up. No deployment pipeline. Ship faster, get feedback faster.

Simpler privacy story — No data ever leaves the device. The privacy policy becomes a single paragraph.

Easier store review — The Chrome Web Store asks detailed questions about data collection. "No data is transmitted externally" is the simplest possible answer.

Zero maintenance overhead — No servers. No database costs. No uptime to monitor.

For an early-stage product, simplicity wins every time.

Shipping Is More Than Code

Once the extension was built, I assumed the hard part was over.

It wasn't.

Publishing to the Chrome Web Store required: store descriptions, icons in multiple sizes, screenshots, promotional assets, a privacy policy, permission justifications, and testing documentation.

As engineers, we tend to think "the product is done when the code works." In practice, that's when the product work begins.

The store required a Privacy Policy URL, which meant I needed a public website. I built a landing page with React and deployed via Cloudflare Pages. Because of the monorepo setup, the build config needed a small tweak:

Build command:    npm run build -w apps/web
Output directory: apps/web/dist

Not complicated, but easy to miss if you've never done it before.

What I Took Away From This

MVP scope matters more than architecture.
A simple product shipped today beats a perfect architecture that ships never.

Local-first is underrated.
For a lot of early products, Chrome Storage (or localStorage) is enough. Not every MVP needs a backend.

Small friction changes behavior.
People don't always need restrictions. Sometimes they just need a moment to pause before acting. The Purpose Check feature taught me that.

Links

• Chrome Extension — Chrome Web Store
• Landing Page
• Follow on X — @keni_1997

I'm building in public and sharing both the wins and the mistakes along the way. If you've ever lost time to YouTube's recommendation engine while trying to learn something, I'd love to hear how you handle it.