Skip to content
ProjectsServicesAboutTech StackContact
Book a call
View case studies
Media2023United States

Podcast Platform

Publishing, distribution and audience analytics for independent creators.

Build something similar
Role
Full Stack Product Engineer
Industry
Media
Client
Startup
Market
United States
Duration
6 months
Status
Live
Ep. 42 · Shipping alone38:14
14:22Published · 6 directories
Overview

What it is

An end-to-end home for independent podcasters: upload an episode, get it transcoded, distributed to every major directory through RSS, and see who actually listened.

Problem

What was going wrong

Creators were stitching together a host, a transcription service and a spreadsheet. Nothing shared data, episode metadata was entered three times, and analytics stopped at raw download counts.

  • Take an episode from upload to published without leaving the product
  • Generate compliant RSS that every directory accepts on first submission
  • Give creators listener analytics beyond a download number
  • Keep storage and bandwidth costs predictable as libraries grow
Solution

How it was built

Uploads go straight to object storage with presigned URLs, so audio never passes through the API. A queued worker transcodes to streaming-friendly bitrates and writes back durations and waveforms. RSS is generated per show and cached at the CDN edge, and playback events stream into a rollup table that powers the analytics views.

Challenges

The parts that were hard

01

Large audio files through a small API

WhyRouting hour-long uploads through the application server tied up memory and timed out on slow connections.

FixThe client uploads directly to S3 with a presigned URL and only tells the API when the object exists, so the server handles metadata rather than bytes.

02

Directories that reject imperfect feeds

WhyEach podcast directory enforces slightly different RSS rules, and a rejected feed blocks distribution entirely.

FixFeed generation was moved behind a validator that runs the directory rule sets before a feed is ever served, so problems surface at publish time rather than at submission.

Outcome

What changed

  • Publishing collapsed from three tools into one flow
  • Feed rejections caught at publish time instead of after submission
  • Bandwidth costs became predictable by serving audio from the CDN rather than the origin
Takeaway

What I'd carry forward

Keep heavy bytes off the application path. Once uploads and delivery moved to storage and CDN, the API stayed small enough to reason about.

Next case study
logistikore.com
Logistikore home page
Logistics SaaSUnited States2026

Logistikore

One operating system for a fleet you own and carriers you broker to. A multi-tenant TMS for freight companies that both run their own trucks and broker loads to outside carriers. Dispatch, fleet, carrier brokerage, accounting and billing sit in one platform, and each tenant's subscription decides which modules unlock.

Next.jsReactTailwind CSSNode.jsCase study
spennypiggy.co
Spenny Piggy home page
Creator economyUnited Kingdom2026

Spenny Piggy

Fans fund creators, and the money survives the round trip. A UK platform where fans back creators through wishlist items, memberships, exclusive content, paid tasks and group Piggy Pots. Money arrives through Stripe Connect, sits under a risk and reserve regime while it clears, and pays out to creators every Friday.

React 18Inertia.jsViteTailwind CSSCase study
Start here

Have a product idea, or one that stalled?

Tell me what you’re building and who it’s for. If I’m the wrong fit I’ll say so on the first call and point you somewhere better.

Book a callSend a message
Email
naveentehrpariya@gmail.com
LinkedIn
/naveentehrpariya
GitHub
/naveentehrpariya
WhatsApp
Direct message

Based in Jaipur, India (GMT+5:30). Replies within one business day.