I Built a YouTube Knowledge Base, Pivoted Three Times, and Killed It
March 2026 — Product #2 in the Idea-to-Market Machine
A month ago, I had an idea that genuinely excited me: what if you could plug your favourite YouTube channels into Claude and query across hundreds of videos, like having a searchable brain of your favourite creators?
I built it. It worked. I used it every day. And tonight, I'm archiving it.
This is the story of YouTubeKB — my second product cycle — and the lessons I'm taking into the next one.
The Spark
I was deep in Claude Code one evening, researching business ideas by watching hours of Starter Story, Greg Isenberg, and Hormozi videos. The thought hit me: I keep rewatching these videos to find specific insights. What if I could just search across all of them?
Within a few days, I had a working prototype. A FastAPI backend that ingested entire YouTube channels — transcribing every video, chunking the text, embedding it into vectors, and making it all queryable through Claude's MCP protocol. Hybrid search with BM25 and vector similarity, reranked with Jina. Five channels, 800 videos, all searchable from my terminal.
It was genuinely useful. I'd type "find me SaaS founders who started with less than $1000" and get six verified case studies with timestamps and revenue numbers, while Gemini hallucinated an entire founder that didn't exist.
I thought I had something.
The Vision: "MCP for YouTube Channels"
The original pitch was sharp: subscribe to your favourite YouTube channels as a searchable knowledge base, queryable from your AI tools. Think of it as the RSS reader of the AI era, but for YouTube.
The target? Technical solopreneurs and indie hackers who already live in Claude Code or Cursor. People like me. The pricing was simple — £9/month for 3 channels, £19/month for all channels. No free tier. Paying signal or nothing.
I built the full stack: FastAPI + FastMCP backend on Railway, Next.js frontend on Vercel, Supabase for auth and pgvector, Stripe for payments, daily sync via GitHub Actions. Eight channels, 728 videos transcribed. Tests passing. The infrastructure was solid.
Pivot #1: The Copyright Scare
First wobble. I spent an evening researching the legality of repackaging YouTube transcripts commercially. The Perplexity lawsuits (Dow Jones, NYT) were fresh. UK fair dealing gives almost no commercial defence. I briefly killed the entire project.
Then I found Transcribr and YouTube Transcript IO — companies openly selling YouTube transcript access and AI search. If they could do it, the legal risk was manageable. Project revived.
Lesson: Research competitors before panicking about legal risk. If others are doing it openly, the sky probably isn't falling.
Pivot #2: "Normal People Can't Use MCP"
This was the big one. I onboarded my first external tester — Andy, a non-technical friend. I walked him through the setup: install Claude Desktop, create an API key, paste MCP configuration JSON into a config file...
He couldn't do it. Not because he's not smart — because MCP configuration is genuinely hostile to non-developers. It requires editing JSON config files, understanding server protocols, and debugging connection issues. For a product targeting "anyone who watches YouTube," this was a death sentence.
So I pivoted. Ripped out the MCP frontend entirely. Built a web dashboard instead. Add channels, see your library, download transcripts. Simple.
Lesson: Your test user reveals everything. One session with Andy taught me more than a week of building alone.
Pivot #3: "Just Ship Transcript Export"
With MCP hidden and AI chat removed (too slow, too shallow, a rabbit hole of prompt engineering), what was left? A tool that ingests YouTube channels and lets you download clean transcripts as markdown files.
I told myself this was a "focused" product. The value prop became: "We index YouTube channels. Download clean transcripts. Use them however you want."
But standing back, I could see what had happened. The thing that made this product special — the AI-powered knowledge base, the cross-channel semantic search, the MCP integration — had been stripped away piece by piece. What remained was a bulk transcript exporter. And there are already a dozen of those.
The Kill Shot
Tonight, I asked myself the honest question: who would pay for this?
Non-technical users? They can't use MCP, and a transcript ZIP file isn't exciting enough at $9/month when free Chrome extensions exist.
Technical users? They could vibe-code the entire thing in a weekend with QMD or any local RAG tool. I know this because I am that user, and I built it myself.
The product was stuck in a dead zone: the people who want it don't need to pay for it, and the people who'd pay for it can't use it.
That's a structural problem. No amount of grinding fixes a structural problem.
What I'm Taking With Me
Technical skills (the real ROI)
This project levelled me up more than anything I've built before:
- MCP servers from scratch. I now understand the protocol end-to-end. My day job at Third Bridge involves AI/MCP product strategy — this hands-on experience is directly applicable.
- FastAPI + async Python. Production-grade API with background tasks, webhook handling, and proper error management.
- Supabase pgvector. Vector databases aren't magic anymore. I know how to ingest, embed, and query at scale.
- Railway deployment. Fast, cheap, good DX. Will use again.
- Vercel + Next.js. Frontend deployment pipeline I can reuse instantly.
- Stripe integration. Checkout, webhooks, subscription management — all wired up and tested.
- Hybrid search (BM25 + vector + reranking). This is genuinely useful knowledge for building any AI product.
I could rebuild the next product's entire infrastructure in a weekend because of what this project taught me.
Product instincts sharpened
- Test with a real user on day one, not day thirty. Andy's session was the most valuable hour of the entire project.
- If your product requires explaining what MCP is, your audience is too narrow. Developer tools need developer distribution channels. Consumer tools need consumer-grade UX. Trying to be both gets you neither.
- Pivoting away from your differentiator is a red flag. When I removed the AI chat and MCP frontend, I should have asked: "What makes this worth building now?" instead of "What's the simplest thing I can ship?"
- Excitement about a market (Trust MRR showing transcript exporters making money) is different from excitement about your product. I got re-energised by someone else's success with a different product for a different audience.
The machine works
This is my second cycle. ConfidentYou (Product #1) got zero sales from my warmest audience — 4,500 email subscribers, 45% open rates, zero conversions. YouTubeKB (Product #2) hit a structural market problem before even launching.
Neither made a penny. Both were worth building.
ConfidentYou taught me the stack (AWS, Cognito, Stripe, email marketing). YouTubeKB taught me the AI stack (MCP, RAG, pgvector, hybrid search) and the product instinct (test early, differentiate or die).
The machine isn't supposed to produce winners every time. It's supposed to produce tested bets and compounding skills. By that measure, it's working exactly as designed.
What's Next
I'm opening the ideas pipeline. The stack is ready. The skills are sharper. The pattern recognition is better.
Whatever Product #3 is, it'll ship faster, test smarter, and get to the honest question — "will anyone pay for this?" — before I've built three pivots of infrastructure.
The 2-hour evening window continues. The machine keeps turning.
This is part of my build-in-public series. I'm a PM at a fintech by day, building AI products in the margins of family life. Two products shipped, zero revenue, all the lessons. Follow along on X @brianguo723.