From Legal Nightmare to Live Product: How I Finally Finished Opticast

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Opticast is a creator-permissioned SaaS platform that automatically converts YouTube video uploads into podcast-quality audio episodes and distributes them to Spotify, Apple Podcasts, Amazon Music, and every major podcast directory — via a standard RSS 2.0 feed.

The moment a creator publishes a new YouTube video, Opticast detects it via YouTube's WebSub (PubSubHubbub) push notification system, extracts the audio using yt-dlp, normalises it to broadcast-standard –16 LUFS with FFmpeg, uploads it to Cloudinary, and regenerates the creator's RSS feed — all without the creator lifting a finger after the initial setup.

Core features:

• Google OAuth onboarding — creators connect their YouTube channel in under 5 minutes


• Real-time video detection via WebSub with a 15-minute polling fallback


• Automated audio pipeline: yt-dlp → FFmpeg loudness normalisation → Cloudinary storage


• RSS 2.0 feed with full Apple Podcasts namespace and Podcasting 2.0 support (chapters, transcripts, funding)


• Directory submission wizard for Spotify, Apple Podcasts, and Amazon Music


• IABv2 analytics — downloads, geographic breakdown, podcast app breakdown, weekly digest email


• Tiered subscriptions (Free, Starter, Pro, Agency) via Polar.sh

Tech stack: Next.js · Django 5 · DRF · Inngest · PostgreSQL · Redis · Cloudinary · Polar.sh · Docker

This project means a lot to me — not just as a technical achievement, but because it represents two years of iteration, a hard pivot, and the stubborn refusal to let a good idea die.

Demo

🔗 Live app: https://opticast-eta.vercel.app/

⚠️ Note on the Google OAuth warning: When signing in, you may see a Google security screen warning about an unverified app. This is expected — the project is registered under the domain satiric-tech in Google Console, which hasn't been verified yet. The OAuth flow is fully functional; the warning is purely a domain verification formality and will be resolved before the public launch.

🎬 Video walkthrough: [https://www.loom.com/share/dd51a9bd1f3641cb906e71dd29f5189b]

Screenshots:

The Comeback Story

Act 1: YouAudio (2 years ago)

Two years ago I built the first version of this idea and called it YouAudio.

The concept was simple: users subscribe to any YouTube channel they like, and the moment a new video drops, they automatically receive the audio version as a podcast episode in their feed. No creator involvement needed.

YouAudio launched, worked, and had real users. Then reality arrived: YouTube's Terms of Service made the user-side audio ripping approach legally untenable. I wasn't processing content with creator consent — I was doing it on behalf of subscribers without it. Continuing down that road wasn't something I was willing to do.

YouAudio still runs today. But I knew the model was broken.

Act 2: The Rewrite

Rather than abandon the core idea, I rebuilt it correctly from scratch as Opticast.

The insight was simple: if creators explicitly authorise access via Google OAuth, every legal concern evaporates — and you end up with a better product anyway, because creators can customise their feed, track analytics, and actually own their podcast presence.

The full rewrite gave me:

Act 3: The Finish Line (This Challenge)

When I found this challenge, Opticast was deployed and functional — but incomplete. The piece missing was the WebSub pipeline: the real-time notification system that detects new YouTube uploads and triggers the audio processing chain automatically.

Without WebSub, Opticast was a manual tool. With it, it's an autonomous pipeline. That's the difference between a prototype and a product.

This challenge gave me the deadline I needed. The WebSub pipeline is now fully implemented, HMAC-verified, and live. Opticast is finished.

My Experience with GitHub Copilot

I built Opticast as a team of two: me and GitHub Copilot. I was the architect — I designed the app structure, wrote the AGENTS.md and SKILL.md rules, chose every external integration, and reviewed and tested every change before it was committed. Copilot was the executor.

Where it saved me the most time

The FFmpeg/yt-dlp audio pipeline was the first major win. Getting the right combination of yt-dlp flags for audio-only extraction, then chaining FFmpeg's loudnorm filter correctly to hit the –16 LUFS broadcast standard, involves a lot of fiddly parameter tuning. Copilot generated a solid first-pass implementation that I refined — work that would have cost me hours of documentation-diving compressed into minutes.

The WebSub callback verification logic was the second. WebSub's challenge-response handshake (the hub.challenge verification flow) is well-specified but verbose to implement correctly. Copilot handled the boilerplate fluently.

Where I had to take the wheel

HMAC signature verification was a significant gap. Copilot implemented the WebSub callback handler but left out the HMAC-SHA1 signature check on incoming push notifications — the step that verifies the payload actually came from Google's hub and not an attacker spoofing the endpoint. Without it, the backend was open to forged push notifications. I caught it during code review, implemented the verification manually, and added it to my AGENTS.md rules so Copilot would include it by default on future security-sensitive handlers.

UI design required more iteration than expected. Opticast uses a custom design system (Soft Minimalism / "Digital Curator" aesthetic — no 1px borders, surface-tier depth instead of shadows, electric violet accent). Copilot's default component suggestions drifted toward generic SaaS patterns. Getting the frontend to match the design spec took several rounds of correction and explicit prompting.

The meta-lesson

The most valuable thing I did was write AGENTS.md upfront — explicit rules about architecture decisions, security requirements, and design constraints. Every time Copilot missed something (like the HMAC check), I updated the rules. By the end, Copilot was generating code that matched my standards on the first pass far more consistently than at the start. The rules file compounds.

Built solo by [@oseni03] — just me, two years of iteration, and a very capable AI pair programmer.