Castos

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me podcast hosting that replaces Castos — and read this first, because one mistake here loses the audience silently.

**The feed URL is stored in every listener's application.** Move it wrongly and they simply stop receiving episodes; nobody tells you, and you find out from a chart. The correct move is at the end of this prompt and it matters more than the code.

STACK
- Node 20+ with Fastify, server-rendered HTML
- SQLite through better-sqlite3, WAL mode
- ffmpeg for loudness normalisation and encoding
- Object storage with a delivery network in front
- Caddy in front

THE DATA MODEL
- shows: id, slug, title, description_html, author, owner_email, language, categories_json, explicit, artwork_path, feed_guid
- episodes: id, show_id, number, season, title, description_html, audio_path, audio_bytes, duration_ms, guid, published_at, status, transcript_path, chapters_json
- downloads: id, episode_id, at, ip_hash, user_agent_bucket, client_name, country, bytes_sent, range_start, range_end, is_counted, exclusion_reason — append-only, and the raw record behind every published figure
- **The episode guid is permanent and globally unique.** It is how every application knows whether it already has an episode; changing one republishes it to everybody

THE FEED, WHICH IS THE PRODUCT
- Valid RSS with the iTunes namespace every directory requires, plus the podcast namespace tags for transcripts and chapters
- The enclosure with a **correct length in bytes and the right MIME type**. A wrong length breaks downloads in some applications and is the most common mistake here
- Correct dates in the required format, in UTC, with a stable order for episodes published in the same minute
- Cache headers and conditional responses: thousands of applications poll this constantly
- **Validate against a real podcast feed validator in the test suite, on every build.** A feed that is invalid in a way one directory tolerates and another rejects is the failure you find weeks later

AUDIO
- Keep the original forever; produce the delivered file from it
- **Normalise loudness to around -16 LUFS for stereo** and report the measured value before and after. An episode much quieter than the last is the most common listener complaint
- Encode at a bitrate suited to speech; the difference on a two-hour episode is substantial
- ID3 tags: title, show, episode number, artwork, chapters
- Serve with range support and correct content length, behind a delivery network — podcast applications download aggressively and in parallel

COUNTING DOWNLOADS HONESTLY
- There is an actual industry standard and following it is what makes your numbers quotable. Roughly: one download per unique listener per episode per 24 hours, only when at least a minute of audio was delivered, excluding known bots and excluding duplicate range requests that reassemble one download
- So record every request with its range header and byte count, then apply those rules at query time. The raw rows stay and the counted figure is derived, so you can always explain how a number was produced
- **Publish the definition next to the number.** An advertiser who asks how you count and gets a vague answer discounts the figure

TRANSCRIPTS
- A local speech model producing WebVTT, linked from the feed and shown on the episode page. It is also the only text a search engine can index about your audio

MOVING, WHICH IS THE PART THAT MATTERS
- Import the existing feed keeping **every guid exactly as it was**
- Then at the old host, replace the feed with a 301 redirect to the new one and **leave it in place for months**. Applications follow it and update their stored address
- Only when traffic to the old feed has fallen to nothing should it be removed
- Submit the new feed to the directories that need it and check each has followed
- **Do not skip the redirect.** Without it every existing subscriber stops receiving episodes

WHAT MATTERS MOST
Feed validity and the redirect. Validate on every build, and treat the migration as the risky part rather than the build.