Listen to dev.to and Substack as a Daily Podcast

If you follow a few dev.to tags and subscribe to a handful of Substack newsletters, your unread count is probably lying to you. There is plenty in there worth a look, and most of it never gets one. A different setup: every morning, listen to a 15-minute AI digest of yesterday's posts on your commute or while you make coffee, then open only the two or three that earn the click. This article covers why dev.to and Substack pile up, what RSS each one actually exposes, how to slice the firehose, and how to wire it into a podcast feed with Lisnify.

Why dev.to and Substack pile up

dev.to and Substack publish at very different rhythms, and that is half of why neither one fits cleanly into your existing reader.

dev.to runs on tags. The site posts dozens of articles a day across python, rust, webdev, react, devops, and the long tail. The signal-to-noise ratio swings hard between tags and within a tag from day to day. Following the global feed gets you a flood; following one tag gets you a slow drip plus the occasional gem you would have missed in the flood. Most readers settle on three or four tags and then check sporadically, which means the good posts get past them anyway.

Substack is the opposite shape. Each newsletter is one author, posting once or twice a week, often in long form. The friction is not volume but inbox decay. A 4,000-word essay shows up at 7 AM, you flag it for later, later does not happen, and three weeks of "I'll read that on the weekend" stack up unread. Paid newsletters compound the guilt because you are watching money sit in the unread pile.

Neither problem is a willpower issue. dev.to wants tag-level filtering you can listen to; Substack wants a slot in your day that is not "sit at a desk and read 4,000 words." Audio works for both, just for different reasons.

What dev.to and Substack expose as RSS

Both platforms publish RSS by default, which makes them unusually friendly compared to most content hubs.

dev.to exposes a few feed shapes:

All latest posts: https://dev.to/feed
Posts in a tag: https://dev.to/feed/tag/{tag} (for example python, rust, webdev, react, kubernetes)
Posts from one author: https://dev.to/feed/{username}

The tag feeds are the useful unit. You can subscribe to two or three at once and treat them as separate slices, which matters later for tuning. Author feeds work for the small group of dev.to writers you want to hear from regardless of topic.

Substack is straightforward: every newsletter exposes its feed at {newsletter-domain}/feed. So Stratechery is at https://stratechery.com/feed, and a newsletter on something.substack.com is at https://something.substack.com/feed. Free posts come through with full text. Paid posts often come through with only a teaser, because the full body is gated behind login. Worth knowing before you assume the feed has everything.

Hashnode sits next door to dev.to and follows the same pattern: each blog at {username}.hashnode.dev/rss.xml, and a global feed for the platform. Medium exposes per-publication and per-author feeds at medium.com/feed/@username, though Medium's full text in RSS is inconsistent depending on the publication's settings.

Several other services already chew on this same input. ListenLater takes article links you send by email or forward as newsletters and turns them into a private podcast episode you subscribe to. The frame is article-by-article: you push something at it, you get an audio version back. That works well for the "I forwarded this Substack to my podcast inbox so I'd actually listen to it" pattern. Lisnify sits next to that rather than against it. The shape here is RSS-first and recurring on a schedule: you hand it a list of feeds once and an episode lands in your podcast app every morning, regardless of which specific articles came in. Two related but distinct jobs, both legitimate.

Pick your slice

Before you wire anything up, decide what one episode contains. Three patterns work well, and you can run more than one in parallel as separate Shows.

One language, daily. A single tag like https://dev.to/feed/tag/rust gives you a focused dev.to episode for whichever stack you actually work in. Slow days produce shorter episodes, busy days surface what was popular. This is the most common starting point.
A small Substack bundle, daily or weekly. Two or three newsletters you genuinely read, blended into one episode. Paid newsletters work here as long as you accept the teaser-only constraint, or you skip them.
A mixed reading-list episode. One dev.to tag plus two Substacks plus one engineering blog. This works if you want a single morning brief that covers everything technical you follow, instead of separate Shows per source.

A note on volume. dev.to global (https://dev.to/feed) without a tag filter publishes more than ten posts a day, which is a problem because Lisnify caps episodes at ten articles. The cap is the right call (longer episodes don't get finished), but it means the global feed will leave good posts on the floor. Tag feeds or a small mixed bundle stay under the cap naturally.

Set it up with Lisnify

The general RSS-to-podcast walkthrough is in the Step-by-step: turn any RSS feed into a personal podcast guide. Below is the dev.to/Substack-specific layer on top.

Register the feeds in a new Show

Sign in to Lisnify, create a Show, and add the RSS URLs in the Sources tab. For dev.to, register each tag separately rather than merging them into one URL. So https://dev.to/feed/tag/python and https://dev.to/feed/tag/rust go in as two sources, not one. This matters two weeks in: when you decide a particular tag is too noisy, you can drop one source instead of rewriting your whole setup.

For Substack, paste each newsletter's /feed URL. Confirm the feed in a browser first to see whether the author publishes full-text or summary-only. If a paid newsletter only puts the teaser in the feed, the episode will reflect that. Get the author's blessing if you plan to keep doing this with their work; private listening for yourself is one thing, but you want the relationship clean.

Pick hosts and language

In the Host tab, choose host voices and the script's speaking style. dev.to articles swing between tutorial-walkthroughs, opinion posts, and "lessons from a year of X," so a calm single-host narration tends to handle the variance well. Substack essays often work better with a two-host conversational style, because long-form arguments benefit from being unpacked rather than read in one register.

If you read English sources but want a different language for the audio, this tab handles the cross-language pair. A common setup is "English-language dev.to and Substack sources, Japanese podcast." The article selection still happens against the original-language source, the script is written in the target language.

Schedule for your morning

Pick daily or weekly with a target hour in your local timezone (the default is UTC, so set yours explicitly). For dev.to-heavy Shows, daily makes sense because the stream itself is daily. For a Substack-heavy Show where the newsletters publish two or three times a week, weekly often produces a more substantial episode. The system runs on the cadence regardless of how many new items appeared, so a quiet week just produces a shorter episode.

If dev.to volume is a concern, consider naming the Show with the rhythm in mind: a Show called daily-rust is easier to reason about than a generic dev-to, especially if you end up running two or three slices in parallel.

Once the first episode generates, Lisnify hands back a private feed URL. Paste that URL into Apple Podcasts, Pocket Casts, or Overcast using their "subscribe by URL" option. Spotify does not accept arbitrary user-supplied RSS URLs, so it is not an option here. The feed URL is built around a UUIDv7 and stays unlisted; the Terms of Service forbid posting it publicly, but private sharing with a small number of people you actually know is fine.

Tune after the first week

Two weeks of listening surfaces obvious adjustments that a first-pass setup will miss:

"The react tag is mostly tutorial walk-throughs and they don't add up to a useful episode" - drop the source.
"The Substack on macroeconomics is great but it's eating the dev tag" - split it into its own Show.
"I want longer per-story coverage on Substack essays and tighter coverage on dev.to" - tweak the per-story instructions in the Script Settings tab.

Per-episode story count lives in Sources; opening, per-story, and closing instructions live in Script Settings.

What works well, what doesn't

dev.to plays well to audio when the post is a story. "How we cut our build time from 12 minutes to 3," "lessons from migrating off DynamoDB," "what I got wrong about Rust traits." The narrative arc translates. Posts whose value is a code listing or a benchmark table do not translate; the episode will mention them, and you will end up reading the original for the actual content.

Substack varies more. Long-form essays, opinion columns, and reported pieces convert cleanly because they were written to be read in order. Newsletters that lean on charts, tables, embedded tweets, or numbered footnotes do not; the audio will skim past the parts that carry most of the argument. Run a Substack-only Show for two weeks before you decide whether the newsletters you picked actually work in audio. Some authors are stronger on the page than they are in your ears.

The general rule is the same one that applies everywhere: audio is a triage layer. It tells you which posts exist and gives you enough sense of each one to decide whether to open the original. It is not a substitute for reading the posts that turn out to matter.

Mix with HN, or keep it separate?

If you also run a Hacker News podcast Show, the question of whether to merge it with dev.to and Substack comes up.

The case for merging: one daily episode covers everything technical you follow, and you only have one feed to subscribe to. The downside is that HN's frontpage and a curated Substack essay don't share a register. Mixed episodes can feel uneven, switching from a quick startup news item to a 4,000-word think piece in the same breath.

The case for keeping them separate: HN is a frontpage signal that moves hourly, dev.to and Substack are slower curated reads. Different rhythms, different listening contexts. A 10-minute HN brief at 6 AM and a longer dev.to/Substack episode for the commute home cover different parts of the day. Most people end up with two or three Shows once they figure out their rhythm; one Show that tries to do everything is usually a transitional state.

Frequently asked questions

How many dev.to tags can I bundle into one Show?

Practically, three to four tag feeds in one Show is the sweet spot. dev.to publishes more than ten posts a day in popular tags, and Lisnify caps episodes at ten articles. Past three or four tags you start losing posts to the cap on busy days. If you want broader coverage, run two Shows side by side rather than one Show with eight tag feeds in it.

Substack paid posts often only show a teaser in RSS. Does that cripple the episode?

It depends on how many paid posts hit the feed in a window. If the newsletter is mostly free posts with the occasional paid piece, the teaser-only handling is fine; the episode will summarize what it has. If you are paying for a newsletter that is mostly paid content, the feed alone won't carry it, and you'll get a thin treatment. The realistic options are to skip paid newsletters in this setup or to talk to the author about how they want their work handled.

Are dev.to comment threads included?

No. The dev.to feed returns the article body and a link back to the original page. Comments live on the page, not in the feed, so the audio summary is based on the post itself. For dev.to posts where the comment thread is the interesting part (the "well, actually" replies on opinion pieces), open the page after listening.

Can I mix dev.to and Substack with my Hacker News Show?

You can, and the mechanics are identical: just add the URLs to the same Show in Sources. Whether you should is a taste call (covered in the section above). The rhythm and tone of the three sources differ enough that most people end up splitting them after a couple of weeks. Start merged if you want fewer Shows to manage, split when the unevenness starts to bug you.

What about the Substack author? Is putting their feed in a private podcast OK?

The feed is public; that's what RSS means. Listening to it privately for yourself, or sharing the resulting episode with a household member, sits comfortably in the same space as forwarding a newsletter to your spouse. Lisnify's Terms of Service forbid posting the feed URL anywhere strangers can find it, which keeps the private-use boundary clean. If you want to do something more public with a particular newsletter (rebroadcasting, redistributing audio versions to a group), that is a conversation to have with the author directly. The system is designed for one listener and a small known circle, not for republishing.

Where to go from here

Start with one slice. A single dev.to tag feed for the stack you actually work in, or two Substack newsletters you've been meaning to read, is enough for a useful first episode. Listen for a week, see whether you keep the habit, then add or trim.

If RSS-to-podcast in general is new territory, the Step-by-step: turn any RSS feed into a personal podcast guide covers the mechanics independent of which sources you pick. If your reading list is heavier on Hacker News than on tag feeds, Listen to Hacker News as a daily AI podcast walks through that case. And if you are still deciding which AI podcast tool fits the job, NotebookLM alternatives compared by job compares the main options by what they're actually built for.