ExpandCast

Independent podcasters lose the value of an episode the day after they publish it. Blog posts, threads, newsletters, clips and thumbnails are what actually feed the funnel, and each one takes hours of manual work. ExpandCast turns one uploaded episode into all five formats in about two minutes. The output sounds like the creator because it's RAG-grounded on the creator's own transcript, never another tenant's.

It's built so a solo creator can hold a derivative-content calendar without an editor or assistant. Multi-tenancy lives in the database, not the route handler. RLS is the only layer that can't be forgotten.

• /01

  Per-tenant by RLS, not by code

  Tenant isolation lives in Postgres policies. Every read or write is checked at the row level. A leak requires breaking RLS, not forgetting a WHERE clause.

• /02

  Voice-matched RAG, not generic AI copy

  Generation runs against the tenant's own pgvector chunks, conditioned on a per-tenant voice profile. The output sounds like the creator, not like an LLM. And it can't quote an episode that doesn't belong to whoever's asking.

• /03

  Streamed from Groq, not polled

  AI SDK v6 streams tokens from Groq to the client. Show notes feel instant because the user reads while the model is still writing.

• /04

  Service-role kept off the browser

  The admin client lives strictly behind the server boundary. Anything the browser can call hits the RLS-bound anon client. The privileged surface never gets exposed.

• Q/01Why pgvector and not a dedicated vector DB?+

  One database for tenant data, audio refs and embeddings means one surface for RLS. Pinecone or Weaviate add a second place isolation can leak from, plus a second auth model to keep in sync with Supabase. pgvector holds up fine until N > 100k chunks per tenant.

• Q/02Why Groq and not OpenAI/Anthropic for inference?+

  Latency. Show notes are the first thing the user sees, and Groq returns tokens 3–5x faster than the alternatives at this model size. When the workload needs a bigger model, AI SDK v6 makes the provider swap a one-line change.

• Q/03Why RLS and not application-level scoping?+

  Application scoping is an open invitation to the 'I forgot a WHERE clause' bug. RLS is the only layer that can't be forgotten, because Postgres applies it before returning a row. If the route handler is wrong, the database is still correct.

• Q/04Why generate the five derivatives on-demand and not during ingest?+

  A creator doesn't know which formats they'll need (blog, threads, newsletter, clips, thumbnails) until they've listened back. Generating all five upfront burns credits on outputs that will never get published. On-demand keeps cost tied to what the user actually wants. The two-minute SLA still holds because RAG + Groq runs in seconds once the embeddings are in place.

• /01

  Build a re-embed migration path on day one. When the embedding model changes (and it will), existing tenants stay frozen on the old vectors. A background cron that re-embeds tenant by tenant would have saved a manual ops pass on every upgrade.

• /02

  Materialize derivative outputs keyed on (episode_id, derivative_type, model_version). Right now every 'blog post' or 'thread' request hits Groq even when the user generated it last week. Caching the materialized output cuts credit burn ~3–5x on revisits, and putting model_version in the key makes invalidation explicit.