Nural News: Any Topic, as a Cited Podcast

Challenge

Grounded AI search had made it easy to get a fresh, cited summary of almost anything, as long as you were looking at a screen. The moments when people actually have time to catch up, like commuting, working out or cooking, are the moments when they can't read.

Inspect Detail

Each existing option failed in a different way. Podcast apps are hands-free, but they're pre-produced, so you get the topics a show picked, recorded days ago. AI search is fresh and cited, but you have to read it. Aggregators and RSS need curating. Voice assistants read a headline or two. None of them could take a niche topic, like a specific policy fight or a sport outside the mainstream, and turn today's coverage into something you could listen to.

There was a second requirement that mattered as much as the first. An AI that summarizes the news without crediting the newsroom takes value from the people who did the reporting. Whatever I built had to send listeners back to the publishers.

The Bet

A briefing you can trust by ear. Type up to three topics. A few seconds later, you hear a short episode that sounds like a broadcast and names every publication it draws on, with each source article linked beneath the player.

That framing set the priorities. Speed to the first episode came first, so the interface had to be nearly empty. Attribution came second, so it had to be spoken in the script, not added as a footnote. Cost was the third, less visible constraint. Generating audio costs real money every time, so the architecture had to keep a popular page from becoming an expensive one.

Process

The core loop: one input, two settings

Inspect Detail

The home page is one sentence and one input: *Get up to speed on any topic*. Each topic becomes a tag when you press Return or ,, and a counter shows how many of the three slots are left. There are two settings, Detail and Voice, and both default to sensible values, so most people never touch them. Your credit balance sits next to the input, so an episode never costs more than you expected.

Everything else was cut. There's no feed to set up, no channels to follow and no onboarding tour. I judged every interface decision by one question: does this make the first episode arrive sooner?

The architecture: four layers, no dedicated backend

Inspect Detail

I built the whole stack myself:

• Gather. A multi-query search over the World News API runs one topic at a time, with retries when a request fails, so it stays inside strict rate limits. It keeps each article's URL and image for the source cards.
• Write. Google Gemini turns a pile of articles into one script: a single narrative with transitions, not a list of headlines read aloud.
• Voice. Google Cloud Text-to-Speech, using Studio neural voices, records the script as a single MP3 in the voice the listener chose.
• Deliver. A Next.js front end plays the episode, with the source cards grouped by topic underneath.

There's no server of my own. Next.js API routes on Vercel run the pipeline. Firebase handles Google sign-in, Firestore holds user state and caches, Cloud Storage holds the audio, and Lemon Squeezy handles credit-based billing. For a solo operator, every server I didn't run was one less thing to be on call for.

Key decision: treat cost as a design problem

Inspect Detail

Every generation calls a language model and a speech engine. Built naively, each page view would trigger one, so cost would rise in step with traffic. The page most exposed to that was also the one I most wanted people to find: the free daily episode.

I designed two caches, one for each kind of episode:

• Server-side, for the daily episode. The first visitor of the day triggers generation. The MP3 is uploaded to Cloud Storage, and a signed URL, valid for seven days, is written to Firestore. Every visitor after that reads the cache. Ten listeners or ten thousand cost the same, and a traffic spike or a scraper costs nothing extra.
• Client-side, for your own episodes. Each custom episode is cached in localStorage for an hour, so replaying it, or coming back to it, plays instantly without another call to the pipeline.

Together they turned a cost that grew with traffic into a fixed one of about $0.05 a day for the daily episode. That decision is the reason one person could run this product profitably.

Prompting for the ear, not the page

Inspect Detail

Text-to-speech reads exactly what it's given, so anything a language model adds for a reader becomes noise for a listener. Out of the box, the scripts had host labels, stage directions and markdown headings, and the voice read every one of them aloud. They also had the transitions that give away machine writing.

The system prompt enforces three rules:

1. No meta-text. No [Host 1]:, no (Upbeat music fades in) and no markdown, because all of it gets spoken.
2. No AI transitions. Phrases like "shifting gears", "moving over to" and "in conclusion" are banned outright.
3. Attribute as you speak. The script names the publication in the sentence that uses it ("according to reporting by Bloomberg…"). A citation list at the end means nothing to someone driving.

The third rule is the product's promise. The spoken attribution makes the briefing trustworthy, and the source cards send listeners to the publishers.

Onboarding: let people hear it first

Inspect Detail

The hardest thing about a new audio product is that people can't judge it from a screenshot. So the front door is a page that asks for nothing: the Daily Podcast, which covers today's top news with the same player and source cards as a custom episode, and requires no account.

Signing up with Google only comes after someone has heard what they'd get. New accounts start with free credits for their own topics, and topping up runs through credit-based billing, so the price tracks what an episode actually costs to make. The daily page turned out to be the highest-converting entry point. It's also the page the server cache was designed for, so the most-visited page was also the cheapest one to serve.

Brand and interface: quiet enough to disappear

Inspect Detail

I designed the brand and interface along with the product. News needs to feel trustworthy, and an audio product should get out of the way once you press play, so the system is deliberately quiet:

• Color. Charcoal (#2E2E2E), gray (#666666) and paper surfaces (#FAFAFA), plus one neon lime (#C5F57C). Because everything else is grayscale, lime always signals either the brand or the next action, like Sign up for free.
• Type. Three styles of IBM Plex: serif for headlines, sans for reading, and mono for controls and data such as Detail: DeepDive and 4 credits.
• Backdrop. A custom component draws faint vertical rules at 4% opacity and recalculates them on resize, giving the page an editorial frame without visual noise.
• Interaction. Topic tags animate into place with Framer Motion. A floating dock sits within thumb reach on mobile, and on small screens the Detail and Voice controls collapse into Vaul bottom sheets.

The tokens live in Panda CSS, which compiles them to static classes at build time, and Radix supplies the accessible primitives underneath.

Impact

The interaction at the center of Nural News, on-demand audio briefings on topics you choose, is one that major platforms have since built into their own products.

Reflection

Cost is a user-experience problem. The two caches never appear in the interface, but they decided what the interface could offer. Without them, a free episode with no sign-up would have been a liability. With them, it became the front door.

Let people hear it before you ask for anything. For an audio product, the daily page did more than any landing-page copy could. If I did this again, I'd launch it first and build sign-up around it, not the other way around.

Trust is spoken, not footnoted. A citation list works on a page and disappears in audio. Writing attribution into the script itself changed the product from a summarizer into a briefing you could rely on.

Constraint kept the interface honest. One input, two settings and a credit count. Every feature I didn't add was one less thing between a listener and the first episode.

What I'd do differently: instrument listening, not just generation. I knew how many episodes were made. I didn't know how far into an episode people listened, and that's the number that would have told me which detail level and which topics were working.

Product screens in this case study are captured from the live site at nural.news. The scripts in the prompting figure are illustrative.