Case study

CultPodcasts AI-led UI update

Why the changes landed the way they did on cultpodcasts.com: content first, business rules under test so AI can contribute safely, and multiple deploys a day because the work spans backend, API management, and frontend — one developer, several features in flight.

Angular 21 · Cloudflare Workers · Durable Objects · Azure Functions · C# · Auth0 · OpenAPI · Cursor

  1. ~5 days Initial UI delivery — content-first homepage through to production cutover. Browse shell in the first ~16 hours; from then on typically several known UI tasks in flight at once rather than one-after-another.
  2. ~4 days UI enhancements on that base — about five to seven known tasks held in parallel (hours-to-days each), not a sequential queue. Still shipping.
  3. 3 systems Same windows across the stack — backend (C# with executable business-rule tests, e.g. Spotify pagination for API quotas), API management (Auth0 / OpenAPI / Workers), and Angular front-end — orchestrated as overlapping streams by one developer. That is why there are multiple deploys a day instead of a single big bang.
CultPodcasts dark-mode homepage with featured episode
Homepage — featured episode first, catalogue metrics, Discover shelf

Content first

The public site already indexed 80,000+ episodes. What needed changing was how that catalogue is presented: put the podcasts first, and use browse patterns people already know from media sites — featured episode, day rails, Discover — which may look a bit like a streaming UI, but only because those patterns work for browsing. Dual theme, docked search, and motion sit behind that, not on top of it.

Same stack underneath: Angular SSR/PWA, Cloudflare Workers and Durable Objects, Azure Functions, CosmosDB. Initial delivery took about five days to cutover; the next ~four days kept roughly five to seven known UI tasks in parallel on that base, washing out older front-end patterns so the next iteration is cheaper.

Why put layers under test

Hundreds of new C# business-rule tests (and matching TypeScript coverage on the website and API worker) are not for a coverage score. They are BDD-style executable rules so an AI agent can read how the system is supposed to behave, contribute more of the implementation, and fail fast when a functional change drifts. Indexing, enrichment, URL submission, hero promote, Spotify pagination — the rules live next to the code.

Spotify pagination is a concrete example: it was improved because of API quotas. Wrong paging burns quota; the rules lock the intended behaviour so the next agent change cannot quietly reintroduce an expensive walk.

500+
C# business-rule tests
300+
TypeScript suite cases
3
Systems in one loop
×N/day
Production deploys

Why multiple deploys a day

Features do not land in one repo. A single change often touches the C# backend (indexer, enrichment, Azure Functions), the API layer (Cloudflare Workers, Auth0, OpenAPI), and the Angular front-end. With one developer orchestrating several features at once, the only workable rhythm is ship each piece when it is ready — multiple production deployments a day across those systems — rather than batching until everything is “done”.

AI (Cursor agents against the live repos) makes that orchestration practical: I set intent and review; agents draft across the stack; the business-rule suite catches functional mistakes early. Old UI code gets washed away where it blocks faster front-end iteration; Auth0 and OpenAPI keep the API contract honest while the public surface moves.

Visit cultpodcasts.com Back to work