Take this with you
- Evaluate playback and exports using your own test episode.
- Keep ownership and recovery access with the show team.
- Document migration before the first release, then retain independent backups.
Map the responsibilities before comparing plans
List the jobs your show needs: storing masters, serving listening files, generating RSS, publishing pages, reporting downloads, and handling access to paid material. A vendor may perform several of these jobs, but a broad feature label does not tell you which ones are included or how they can be exported.
Ask who owns the account, domain, feed address, and media files. Give the production team appropriate roles rather than sharing one password. Keep a separate inventory of directory accounts and recovery contacts so an editor's departure does not leave the show without an administrator.
Check the actual listening path
Apple's technical requirements include publicly addressable podcast RSS and media hosting that supports HTTP HEAD and byte-range requests. Those details matter because podcast applications must inspect and retrieve media reliably. Use the current requirements as a concrete compatibility check when evaluating a public feed. [1]
Test one representative episode on a phone and a desktop, including a seek to the middle and a fresh download. Check artwork loading, episode descriptions, and the link back to the show page. Record which device, app, network, and file you used so a reported problem is reproducible.
Compare costs against your release pattern
Create a worksheet using your expected episodes per month, average file size, archive size, and team seats. Include any separate charge for transcription, dynamic ads, extra bandwidth, premium feeds, or export. Request the provider's current terms; avoid basing a long-term decision on a temporary promotional headline.
Model a quiet month, a normal month, and a month with substantially more downloads. These are planning scenarios, not traffic predictions. The exercise should reveal whether growth changes your bill gradually, triggers a new tier, or requires a conversation with support before an episode can be delivered.
Treat your feed address as a continuity asset
Ask whether your plan supports a feed address under a domain you control, and what maintenance that setup requires. A custom address can be useful, but ownership is only meaningful if you retain the account access and technical ability to keep it functioning during a provider change.
Apple documents feed migration using a server redirect and warns creators to preserve episode GUIDs. A migration plan should therefore include the old feed, the replacement feed, persistent identifiers, and a period of observation. Read the specific instructions for every directory your show uses. [2]
Keep a recovery copy outside the publishing account
Maintain copies of original recordings, final audio, artwork, transcripts, show notes, and episode metadata in a location controlled by the production team. Store an export of the feed when you publish. Give the files meaningful names and keep the association between an episode and its stable identifier.
Practice restoring one older episode into a test location. You are checking whether the materials are complete, permissions are known, and a different team member can understand the archive. A backup that only one person knows how to interpret is a weak foundation for a growing show.
Separate public publishing from restricted access
Public discovery and paid access often need different delivery paths. A public show may offer a trailer or selected episodes while a membership service manages bonus material. Write down which system grants access, which system revokes it, and what a listener receives after a successful purchase.
Do not assume a link hidden from navigation is private. Ask a prospective provider how it protects member media, rotates exposed credentials, handles cancellation, and supports common listening apps. For token-based access, test the exact wallet and account flow before describing it as available to listeners.
Make the final choice with a rehearsal
Use a short acceptance checklist with a real test episode: upload, metadata edit, scheduled release, feed refresh, playback, transcript access, export, and support request. Include the people who will do the weekly work. A workflow that looks efficient in a demonstration may behave differently with your files and review process.
Choose the host whose verified behavior fits your show and whose exit process you understand. Keep the evaluation notes with your production documentation. Revisit them when the release schedule, team size, advertising model, or membership offer changes, rather than replacing infrastructure because a new feature sounds attractive.
Sources & further reading
Primary references for this guide. Standards and service requirements may change; check the current source before publishing.