What it took to make an RSS reader feel like one continuous audio briefing

PressPlayed.com — Fri, 28 Aug 2026 10:15:17 +0000

Most RSS readers optimize for scanning: unread counts, compact lists, folders, and a fast path to the original page.

I wanted a different path through the same material. My saved articles and recurring subjects kept piling up, but the useful time I had was often time when looking at a screen was inconvenient. So I built PressPlayed, a mobile-first RSS reader that turns sources and topics into one continuous narrated briefing.

The product idea sounds simple. Making it feel like one uninterrupted piece of audio was not.

The product model: briefings, not an inbox

A source is a publication or feed. A briefing is the listening experience assembled from one or more sources.

That distinction matters because the user is not trying to clear an inbox. They are trying to press play on something coherent: a morning reading list, a housing-market briefing, coverage of Fed interest rates, a hobby, or any other recurring subject.

PressPlayed supports two ways to build one:

Choose publishers you already trust.
Choose a topic and let the service find current coverage across sources.

The second path is important. Many people know what they care about but do not know which RSS feeds publish the best coverage. Topic discovery lets the subject come first while still showing where every article came from.

Constraint 1: narrate the article, not the web page

A feed item is only the start. Sometimes it contains full text; often it contains a teaser and a link.

The server fetches the article safely, extracts the readable content, and removes page chrome, repeated captions, bylines, and other text that sounds especially awkward when spoken. Extraction failures are recorded instead of silently turning into a bad narration. Publisher refusals and real paywalls are respected.

This part is less glamorous than TTS, but it determines whether the result sounds like an article or a browser reading random furniture aloud.

Constraint 2: segment synthesis without segment-shaped playback

Long articles cannot be synthesized as one enormous request. PressPlayed splits text into roughly 850-character segments, synthesizes and caches each segment, and asks the browser to play them as a single stream.

The important detail is that the audio element keeps one source. Bare MP3 frames are appended to one MediaSource buffer in sequence mode. Changing the audio source at every segment or article boundary made mobile background playback fragile; keeping one stream also makes boundaries disappear for the listener.

The player fetches ahead, retries individual segments, and can move from one article to the next without turning the queue into a playlist the user has to manage.

Constraint 3: keep the first audio fast when several people arrive

Text-to-speech is the expensive path. A naive FIFO queue lets one listener fill every slot with a long article while everyone else waits.

PressPlayed admits synthesis work fairly across accounts and gives priority to the segment a listener is audibly waiting for. The client limits requests in flight, while cached audio skips synthesis entirely. The goal is not maximum benchmark throughput; it is minimizing the time until each person hears useful audio.

Personalization should remove work

The controls are intentionally small:

narrator choice
language choice
minimum article length
skip played articles
muted words and phrases

Muted terms can be global or briefing-specific. A person who does not want gambling coverage, for example, can remove articles containing “gambling” or “sportsbook” before they reach the queue.

What I am trying to learn

PressPlayed is live, free to try, and does not require a credit card. The public page includes a briefing sample and a short portrait tour of the real mobile interface:

Hear the sample and take the PressPlayed tour

I would especially value feedback from people who use RSS or build audio products:

Is “sources become briefings” an intuitive model?
Would you start from known publishers or from a topic?
Which portability feature matters most: OPML import/export, visible raw feed URLs, or something else?
What would make the first briefing worth returning to tomorrow?

I am happy to answer technical questions about the extraction, queueing, or browser-audio decisions.