PodToSite

Day 13 of 30 — Discoverability arc opens

PodToSite is YouTube-first, LLM-native podcast websites. Live today at podtosite.com; canonical reference deployment running for Tales From The Sky Lounge at tftsl.podtosite.com. Co-built with James Liebman, who has been the operator-anchor on PodToSite since the first commit and runs the day-to-day customer side of the business.

Day 13 opens the Discoverability arc. After three days of Cogle GTM cluster proof — CounselExpress, ChamberAdvance, and PlanCheck on Days 10, 11, and 12 — the calendar pivots from line professionals inside regulated processes to how things become findable when search is no longer a search box. PodToSite is the entry; tomorrow’s GEOPress (the WordPress plugin for Generative Engine Optimization, 590M+ addressable sites) is the extension. Two products, one thesis: search is being unbundled into LLM answers, and the websites that win the next ten years are the ones built to be read by a model.

What it does

PodToSite is a multi-tenant SaaS that turns a YouTube-published podcast into a full LLM-discoverable website without a CMS, a theme shop, or a WordPress install. The host points PodToSite at a YouTube channel (or a playlist within one); the system handles the rest.

The host workflow: Connect a YouTube channel through the host portal. Pick the playlist that is the show (or treat the whole channel as one show). Choose a subdomain (yourshow.podtosite.com) or attach a custom domain. PodToSite ingests the back catalog in the first thirty minutes — pulling video metadata, thumbnails, descriptions, and either YouTube auto-captions or, if those don’t exist, transcripts generated by Whisper on the audio track. Claude on AWS Bedrock then produces, per episode:

• A chaptered transcript with timestamp-anchored section headers — the kind of thing a human can skim, but more importantly the kind of thing an LLM can quote with attribution.
• An episode summary at three lengths (one sentence, one paragraph, one page) so an LLM crawler answering “summarize the latest episode of [show]” has the right grain available at the right depth.
• Per-episode JSON-LD that is triple-typed (PodcastEpisode + Article + VideoObject) so structured-data consumers — Google, Bing, Apple Podcasts directory feeds, and increasingly the LLM training-data pipelines — get the canonical metadata in the shape each one expects.
• An llms.txt block per episode stitched into the show-level llms.txt and llms-full.txt files at the site root. The block carries the episode title, guest names, three-length summary, chapter list, and a short “what this episode is for” framing line written explicitly for an LLM reader.
• A per-episode OG card generated server-side from the episode title and a frame from the YouTube thumbnail — so when somebody pastes the URL into LinkedIn, Substack, or a Discord, the preview is a designed object, not a YouTube screenshot.
• A canonical link back to the YouTube watch URL with the embed inline above the transcript — PodToSite is built to send traffic to YouTube, not to capture it. YouTube is the source of truth and the host’s monetization layer; PodToSite is the discoverability and SEO/GEO surface layered on top.

The new-episode flow: When the host publishes a new YouTube episode, a webhook (or the every-hour ingest poller for hosts without a webhook configured) detects it. The new episode page is built, the JSON-LD enriched, the llms.txt updated, and the static tenant site rebuilt and re-deployed to S3 + CloudFront in under five minutes from YouTube publish. The LLM-discoverable version of the show exists the same hour the YouTube version does — which is the part the legacy podcast-website category got structurally wrong.

The GEO-native stack

Three architectural choices put PodToSite on the right side of how discoverability actually works in 2026:

1. llms.txt is a first-class output, not an afterthought. Every tenant site ships /llms.txt and /llms-full.txt at the root, generated from the same Bedrock pipeline that writes the JSON-LD and the per-episode summaries. The format follows the Anthropic-popularized convention — a short index file that points LLM crawlers at the long-form machine-readable artifact. Most podcast websites have no llms.txt. PodToSite’s tenants have one the moment they go live, and the index updates within minutes of every new episode.
2. Astro 5 static render + CloudFront, not server-side React. The output is real HTML served from edge — fast for human visitors, fast for crawlers, and crucially, legible to the LLM crawlers that don’t execute JavaScript. A SPA podcast site renders empty for a non-rendering crawler; a PodToSite tenant renders fully. The architecture decision is identical to what the silverbackcto.com site itself runs on — and for the same reason. If the goal is to be read by a model, the page has to exist when the model arrives.
3. YouTube as the source of truth, not a destination. The host already publishes to YouTube. The host already cares about YouTube watch time, YouTube SEO, YouTube channel growth. PodToSite is built to amplify the YouTube channel by giving the show a parallel surface that the LLM-answer-engines can index — not to compete with YouTube for the host’s attention or for the listener’s click. The embed-first, canonical-link-to-YouTube design is the explicit acknowledgment that the discoverability layer should make the upstream platform stronger, not weaker.

Multi-tenant SaaS with custom domain support at the Enterprise tier; per-tenant subdomain (*.podtosite.com) at the default tier. Per-tenant DynamoDB partition (TENANT#<showId>), per-tenant S3 prefix, per-tenant Cognito user-pool group, per-tenant Bedrock invocation budgets. Cross-tenant query paths don’t exist in the API surface.

The thesis behind the launch — discoverability infrastructure is the new SEO

PodToSite sits inside Theme #3 of the 30-day run — Websites for LLMs, not people. The framing isn’t that humans stop being readers. Humans are still readers, and the PodToSite tenant pages are designed for them too. The framing is that the first reader of a podcast website in 2026 is increasingly a model — and the model is the gatekeeper for whether a human ever ends up on the page at all.

When somebody types “best business podcast about PE/VC operators” into ChatGPT, Claude, or Perplexity, the answer is being assembled from training data and live retrieval against the public web. If a show has hundreds of thousands of YouTube plays but no LLM-readable website, the show is structurally invisible at that step of the funnel. The recommendation engine has nothing to quote. The legacy podcast-website tools never had to solve for this; the websites they generated were built for the post-2010 search-engine landscape, which assumed Google would crawl JavaScript, parse a sidebar, and decide a relevance score. Generative engines assemble answers differently. They want structured data, transcripts, summaries, and llms.txt. PodToSite ships all four by default, on every episode, automatically.

This is the same architectural posture the silverbackcto.com site has been running since Day 1 — llms.txt, llms-full.txt, JSON-LD per page, full content collections, RSS, no JavaScript dependency for the canonical content. The decision generalizes. PodToSite is the productization of that decision for a specific market: YouTube-published podcasters who need to be findable in LLM answers without becoming a WordPress shop.

The Day 14 launch — GEOPress, the WordPress plugin for GEO — is the same thesis applied to the 590M-site WordPress universe. Different surface (CMS plugin vs. SaaS site builder), different operator (different team, different distribution channel), same load-bearing argument: the websites that survive the search-to-LLM transition are the ones that are explicitly built to be read by a model. PodToSite is that argument shipped for podcasters. GEOPress is that argument shipped for everybody on WordPress.

The TFTSL case study — the canonical reference deployment

The public reference for PodToSite is Tales From The Sky Lounge at tftsl.podtosite.com. TFTSL is the business podcast for PE/VC operators and founders that runs alongside this thirty-day build (the Week 1, 2, 3, 4 wraps are recorded and published as TFTSL episodes). The site is its own proof — every episode page carries the chaptered transcript, the three-length summaries, the triple-typed JSON-LD, the per-episode llms.txt block, and the YouTube embed above the fold.

The dogfooding case is the kind of thing that should not need to be said but always does: PodToSite is the site that publishes the case study that proves PodToSite. The Week 1 TFTSL wrap that dropped on Day 8 is on the site. The Week 2 wrap that drops Thursday will be on the site within five minutes of YouTube publish. Every Substack article in the thirty-day series links to the TFTSL site for the episodic context — and every one of those links is now, by design, an LLM-readable surface, not a YouTube screenshot.

Hosts who care about the LLM-discoverability question already are the ones who notice the architectural difference inside the first minute of looking at the TFTSL site. Hosts who don’t care yet will care in a quarter. PodToSite is the surface that handles the architectural shift the moment the host decides it matters.

Pricing & business model

• Free tier: one show, up to 50 episodes, *.podtosite.com subdomain only, weekly ingest poll, standard llms.txt generation. Lets a new host stand up a discoverable site in under an hour with zero commitment.
• Pro: $49/month per show. Unlimited episodes, custom domain (with cert + routing managed), real-time YouTube webhook ingest, Claude-generated chapter and summary upgrades on every episode, advanced JSON-LD options, per-episode OG card customization. The price point for the working podcaster.
• Enterprise: $299/month per show or $2,990/year. Multi-show network support (one parent brand, multiple show subdomains under it), white-label removal, dedicated AWS region routing if compliance requires, custom llms.txt schema extensions, hands-on onboarding. For networks, agencies, and brands running portfolios of shows.
• Add-on — PodToBook: the Day 26 venture-cluster sibling product. PodToSite Pro and Enterprise tenants get a one-click intake into PodToBook (the Andrew Brummer-led service that turns a show’s transcripts into a book draft). Bolt-on revenue, same source material, different operator.

The unit economics are straightforward. Bedrock costs per episode (chapter generation + summary + JSON-LD enrichment + llms.txt block) run about $0.18–$0.35 depending on episode length; CloudFront + S3 hosting per tenant runs $1–$4/month at typical traffic. The $49/month Pro price clears 90%+ gross margin once a tenant is past the back-catalog ingest. The back-catalog ingest itself is the one-time AI cost that the tier pricing absorbs — a 200-episode back catalog costs $36–$70 in Bedrock spend amortized into the first three months of subscription revenue.

The Velocity Process notes

What Claude Code handled: the Astro 5 + Tailwind v4 tenant-render layer (per-episode page template, show home page, hosts/about page, RSS feed reconstructor, sitemap.xml + sitemap-news.xml + sitemap-podcasts.xml, the per-tenant theme overrides, the OG card SVG → PNG render pipeline); the Node.js 20 ingest workers (YouTube Data API channel + playlist + episode fetch, transcript pulling with the auto-caption-first / Whisper-fallback decision tree, the new-episode webhook handler, the every-hour fallback poller, the Bedrock InvokeModel calls for chapter generation / summary / JSON-LD enrichment / llms.txt block synthesis); the Astro static build + S3 sync + CloudFront invalidation pipeline that fires per tenant on every new-episode event; the multi-tenant Cognito setup with host-role and admin-role user-pool groups; the Stripe Billing integration with the per-show subscription product + the per-episode AI-overage metered usage; the VelocityStack CDK v2 stack with per-construct files for Ingest, Render, CDN, Auth, Database, Billing, and Monitoring; the canonical-domain + custom-domain Route53 + ACM provisioning flow for tenants attaching their own domain; the tftsl.podtosite.com deployment that is the canonical reference customer.

What required human judgement: the YouTube-source-of-truth architectural posture — the simpler thing would have been to make PodToSite an RSS-first product (read the podcast’s RSS, generate the site, ignore YouTube), and the simpler thing would have been wrong because the audience growth in the category has migrated to YouTube and the canonical asset host now publish is increasingly the YouTube channel, not the RSS feed. Leading with the YouTube ingest, treating RSS as a secondary input, and designing the per-episode page around the YouTube embed is what makes PodToSite legible to a host whose primary publishing surface is YouTube. The llms.txt-first product framing — choosing to put the LLM-discoverability surface in the foreground of the marketing copy (rather than burying it as a technical feature) is the editorial call that distinguishes PodToSite from a generic podcast-website builder. The hosts who matter to PodToSite’s first 1,000 customers are the hosts who already know what llms.txt is and care that their site has one. The Astro-static-render architectural decision — the simpler thing would have been a React SPA per tenant, and the simpler thing would have produced sites that are structurally invisible to non-JavaScript-executing LLM crawlers. The Astro + CloudFront posture is the same posture the silverbackcto.com site itself runs on; productizing that posture is the entire PodToSite thesis. The dogfooding decision — running tftsl.podtosite.com as the public reference deployment rather than a fictional demo site is the kind of move that costs nothing to set up and earns disproportionate credibility on the marketing page; the TFTSL site is its own case study, every Week wrap that drops on TFTSL through the rest of the thirty-day run reinforces the PodToSite proof.

What broke: the YouTube Data API quota hit a soft limit on Monday afternoon during the back-catalog ingest test for the TFTSL show. The fix was a switch from per-episode videos.list calls to a batched videos.list with up to 50 IDs per request (about a 30x quota reduction) plus a token-bucket rate-limiter at the worker layer. The other near-miss: the per-tenant Stripe Connect onboarding flow had a subtle bug where the custom-domain attach happened before the Stripe subscription confirmation, which would have let a host stand up pod.<their-domain>.com without ever paying. Caught Monday evening by James in QA; fixed by reordering the Stripe-confirmation gate in front of the Route53 + ACM provisioning step.

What I’d do differently: lock the YouTube-first decision two weeks earlier. The original v1 PRD treated YouTube and RSS as equal-priority inputs; the v2 decision (YouTube as the primary, RSS as the fallback) only crystallized in the back half of the build cycle, which forced a partial refactor of the ingest pipeline and the per-episode page template. The structural lesson is consistent with what Day 12’s PlanCheck retrospective named: architecture decisions on AI-pipeline products should be validated against real test data on day 3 of the build, not day 17. The TFTSL back-catalog ingest was the test data that proved the YouTube-first posture was the right one — running that test in the first 72 hours of the build (rather than the last 72) would have saved the refactor.

What’s next this week

• Day 13 evening (tonight): the first wave of inbound podcaster intake opens — podtosite.com/start carries a YouTube-channel-URL field that auto-generates a preview of the first episode page (rendered server-side from a single Bedrock call) before the host commits to a subscription. The “see your site before you pay” intake is the conversion lever.
• Day 13 evening (tonight): the TFTSL Week 2 wrap drops on tftsl.podtosite.com — covering the Cogle GTM cluster (Days 9-12) and opening the Discoverability arc. The Week 2 wrap is itself the live demo of the new-episode-to-live-LLM-readable-page flow.
• Day 14 (Thu May 14): GEOPress — WordPress plugin for GEO. The Discoverability arc continues; 590M+ WordPress sites are the addressable market. Same thesis, different surface.
• Day 15 (Fri May 15): Audience-pick build + “I’ll Build Your Idea” reveal. TFTSL Week 2 wrap rebroadcast across the channels.

Want to talk

If you’re a podcaster on YouTube who has watched the LLM-answer-engine shift and wondered why your show is invisible when somebody asks ChatGPT for “the best podcast about [your topic]” — paste your YouTube channel URL at podtosite.com/start. The preview is instant; the first 50 episodes ingest in 30 minutes; the site goes live on a *.podtosite.com subdomain in the same hour. Custom domain attach is a click.

If you’re a podcast network, agency, or brand running a portfolio of shows and looking for a single discoverability layer underneath all of them — the Enterprise tier handles multi-show network deployments with white-label removal, custom llms.txt schema extensions, and dedicated onboarding. Email hello@podtosite.com or book through Calendar.

If you’re a host whose show is RSS-only (no YouTube channel) — PodToSite still works, with RSS as the primary input and the same LLM-discoverable output. The YouTube-first framing is the lede because that’s where the audience growth is; the architecture handles RSS-only shows on the same code path.

PodToSite is co-built with James Liebman. Live now at podtosite.com; canonical reference at tftsl.podtosite.com. The Discoverability arc opens here. Tomorrow: GEOPress — WordPress’s turn.