Transistor

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 Transistor: the audio, the feed every app reads, and download numbers I can quote.

Read this first, because it is the one real risk. The feed URL is what every podcast application has stored. Moving it wrongly loses your entire audience silently — they simply stop receiving episodes and nobody tells you. There is a correct procedure and it is in the migration section below; read it before you move anything.

STACK
- Node 20+ with Fastify, server-rendered HTML
- SQLite through better-sqlite3, WAL mode
- ffmpeg for transcoding and loudness normalisation
- Object storage or a good disk, with a CDN in front for the audio
- Caddy in front

THE DATA MODEL
- shows: id, slug, title, subtitle, description_html, author, owner_email, language, categories_json, explicit, artwork_path, website_url, copyright, type, feed_guid, custom_domain
- episodes: id, show_id, number, season, title, subtitle, description_html, audio_path, audio_bytes, duration_ms, mime, guid, published_at, status, episode_type, explicit, artwork_path, transcript_path, chapters_json
- audio_versions: id, episode_id, kind, path, bitrate, bytes, loudness_lufs — the original upload kept untouched, plus the delivered encode
- 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
- distribution: id, show_id, platform, external_id, status, submitted_at
- The episode guid is permanent and globally unique. It is how every application knows whether it has an episode already, and changing one republishes the episode to everybody

THE FEED, WHICH IS THE PRODUCT
- Valid RSS 2.0 with the podcast namespaces: the iTunes tags every directory requires, and the newer podcast namespace tags for transcripts, chapters, funding and person credits
- The enclosure with a correct length in bytes and the right MIME type. A wrong length breaks downloads in some applications, and it is the most common mistake
- Episodes in reverse chronological order, with a configurable limit for very long back catalogues
- Correct dates in the required format, in UTC, and a stable ordering for episodes published in the same minute
- Cache headers and conditional responses, because thousands of applications poll this feed constantly and being a good citizen keeps you off their slow list
- 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
- Accept any upload, keep the original forever, and produce the delivered file from it
- Normalise loudness to the broadcast target — around -16 LUFS for stereo podcasts — and report the measured value before and after. An episode that is much quieter than the one before it is the most common complaint listeners have
- Encode to a sensible bitrate: mono voice needs far less than stereo music, and the difference on a two-hour episode is substantial
- Write ID3 tags: title, show, episode number, artwork, chapters
- Serve with range support, correct content length, and a CDN in front. Podcast applications download aggressively and in parallel

COUNTING DOWNLOADS HONESTLY
- The industry has an actual standard for this, and following it is what makes your numbers quotable to an advertiser. Roughly: count 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 its byte count, then apply those rules at query time. The raw rows stay, the counted figure is derived, and 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
- Bots and prefetchers flagged with the reason, never dropped
- Downloads by episode, by day, by client application and by country, all computed from the rows

TRANSCRIPTS AND CHAPTERS
- Transcription with a local speech model, producing a WebVTT or SRT file linked from the feed with the podcast namespace tag
- Editable, because automatic transcription of names and jargon is always wrong somewhere
- Chapters as a JSON chapters file, with titles, images and links
- Both are also a search-engine surface: a transcript on the episode page is the only text a search engine can index about your audio

THE WEBSITE
- A page per episode with the player, the description, the transcript and the chapters, at a permanent URL
- The show page, an embeddable player, and share images generated per episode
- Fast, server-rendered, dark and light

MIGRATION, THE PART THAT MATTERS
- Import the existing feed: episodes, guids, dates and audio, 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 URL
- Only after the 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 one has followed
- Do not skip the redirect. Without it, every existing subscriber stops receiving episodes and you find out from a chart

OPERATIONS
- .env: DATABASE_PATH, STORAGE_PATH, BASE_URL, SESSION_SECRET, CDN_URL, HASH_SALT, GEOIP_DB_PATH
- Migrations on boot, each once
- Bandwidth is the real cost: measure it per episode and watch it
- Nightly backup of the database and the original audio — the originals are irreplaceable
- Health endpoint that validates the feed and checks storage

WHAT MATTERS MOST
Feed validity and honest download counting. Validate against a real validator on every build, and implement the counting rules properly, because those two are the only things standing between you and an audience that quietly disappears or numbers nobody believes.

Give me the repository, the feed generator with its validation tests, the importer with the redirect procedure documented, migrations, .env.example, and a README that opens with the migration steps.