RH

things i've taken apart

short notes on product gaps and tradeoffs — sharper than a thread, lighter than a whitepaper.

01April 2026Why YouTube has no native competitor analytics

YouTube Studio is genuinely well-designed for what it does. The dashboards are clean. The audience retention graph might be the most actionable analytics view I've seen outside paid enterprise tools. It is, by most measures, good software.

But there's one enormous blind spot built into it by design: you cannot see anyone else's numbers. Not a competitor's view count trend. Not their upload cadence. Not even a rough ballpark of what a sponsored post in your niche is worth.

This is not a technical limitation. YouTube has all of this data. The decision is strategic.

Surfacing competitor metrics would push creators into a pure imitation loop — copy whatever's working, chase whoever's winning, race to someone else's ceiling. YouTube would rather you focused inward. The algorithm rewards genuine quality over engineered virality, and surfacing rival stats would undermine that nudge. Better content beats copied content. YouTube's growth depends on that being true.

The side effect is a genuine market gap. Agencies running brand deals, independent creators pricing their sponsorships, and marketers benchmarking a niche have no native tool. They're screenshotting Social Blade and building spreadsheets.

That's exactly why ChannelSpy exists. Not to spy — great name though — but to give context. Knowing that channels in your niche average 40K views per video changes how you set goals, pitch clients, and decide what's worth building.

The lesson that stuck: the most interesting products don't live where the obvious problems are. They live in the gaps left by someone else's deliberate strategic choice.

02March 2026The UX problem with AI browser extensions

The dominant UX pattern for AI browser extensions goes like this: notice the problem → click extension icon → panel opens → paste or select text → click summarise → wait → read result → close panel → return to page → realise you lost context.

That's eight steps. For a tool that exists to save you time.

The core insight behind SkipTheTerms was simple: the trigger — landing on a Terms of Service page — is completely predictable. The URL contains /terms, /privacy, /legal. The page title says it. The extension doesn't need to wait for the user to initiate anything. It can detect the context automatically, pre-trigger the summarisation in the background, and surface the result with a single badge. No panel. No copy-paste. No mental context switch.

This collapsed the interaction: arrive at terms page → see badge → click once → read summary.

The backend had to match this UX promise. If the summary takes 8 seconds, the friction isn't gone — it's just relocated. Supabase caching on document hash was the fix. Cache hits return in 50ms. Fast enough to feel instant. Not fast. Instant. There's a difference, and users can feel it.

The thing I most underestimated: backend latency isn't just an engineering metric. It is a UX decision. Every second a user waits is a second they're thinking about the wait, not the result.

Zero-friction doesn't mean fewer features. It means removing the distance between the problem and the answer.

03February 2026You're probably spending 10× more on LLM calls than you need to

When I first launched SkipTheTerms, every request hit the Groq API fresh. Llama 3.3 70B, every time, for every user, for every document. Clean. Expensive. Stupid.

The problem became obvious fast: Terms of Service documents don't change. The same GDPR policy gets read by hundreds of users. I was paying API credits to summarise an identical 5,000-word document dozens of times a day. Different users. Same document. Same result.

The fix was two hours of work: hash the document content on arrival, check Supabase for an existing summary, return it if found, call the LLM if not, store the result. Cache hit rate hit 70% within the first week.

Cost reduction: 40%. Latency on cache hits: 50ms vs ~3 seconds cold. User experience: the thing felt instant on the majority of requests.

The broader point is that most LLM applications have natural caching surfaces — repeated queries, identical documents, common prompts — and most developers skip them entirely because they're thinking about model quality rather than call frequency.

The uncomfortable truth: a worse model with a cache is often a better product than a better model without one. Your users probably cannot distinguish GPT-4o from Llama 3.3 70B on a summarisation task. They can absolutely tell the difference between 50ms and 3 seconds.

Optimise for the experience, not the benchmark.