When I tell people what Junco is, the most common follow-up is some version of: "isn't that just text-to-speech? Doesn't [reading app] already do that?"
Yes and no. Almost every reading app has a listen button. They are almost all bad. The why is interesting, and it's the reason Junco exists as its own thing instead of as a feature inside a reader.
Here's the short version, then the long one.
Short version
A "listen" button inside a reading app is a feature. A podcast-shaped product is a different thing. They share a technology (TTS, more recently neural TTS) but they have different defaults, different UX, and different daily habits.
If you actually listen, the difference is enormous. If you mostly read, you'll never notice it.
The problem with "listen" as a feature
Imagine you opened your favorite podcast app and the experience was: open the app, scroll through a list, tap a show, tap an episode, tap a play button buried inside the article view, hope it doesn't restart from the top, lock your screen, walk to the kitchen, look back to discover the audio paused because you locked the screen.
That's roughly what every "listen to this article" feature in a reading app feels like. It's not because the people building those features are bad. It's because audio inside a reading-first product is structurally a second-class citizen. The defaults all favor reading: the home screen is a feed, the player is a sub-view, downloads are not a real concept, lock-screen controls are inconsistent, push notifications fire when content arrives but not when audio is ready, the queue is shaped like a saved-articles list instead of a play queue.
You can fix any individual one of these. You can't fix all of them without rebuilding the product around audio. At which point you've built a different product.
What changes when audio is the default
A few decisions shift completely:
Cadence. Reading apps push when content arrives. Audio apps push when an episode is ready to play, which is a different moment. For Junco that's after the morning batch finishes generating. The notification means "there's something to listen to right now," not "you have one more thing to read later."
Queue model. Reading apps have a "saved" list. Audio apps have a play queue. They look superficially similar. They behave very differently. A saved list is a backlog you feel guilty about. A queue is the next thing that plays when the current thing ends. The first one accumulates dread. The second one accumulates listens.
Episode shape. A reading app shows you a newsletter as a newsletter (subject line, sender, date). An audio-first app needs to make decisions about how a newsletter sounds: how long is the episode, do you stitch multiple short ones together, where does each one start and end, what's the intro, what's the outro. Those decisions only really make sense if audio is the default product, not a side door.
Voice. Most TTS in reading apps is the system TTS (the OS voice, often a clinical robot). To get to "this sounds like a podcast" you need to invest in real TTS providers, voice selection, prosody tuning. That investment doesn't pay back unless audio is core to the product.
Offline. Reading apps generally don't bother with audio downloads because audio is opt-in. Podcast apps treat offline as a baseline expectation because most listening happens away from wifi. Forgetting to download a single episode for a flight is the kind of thing that breaks trust in an audio app, and it's the kind of thing nobody bothers to ship in a reading app.
None of these are huge on their own. Together they're the difference between something you use a few times and something that becomes a habit.
Why I didn't just build a feature
I tried, briefly. The first prototype of Junco was going to be a reader with a really good listen button. After a couple weeks I realized I was just trying to build a podcast app inside a reader because every problem I cared about was an audio problem. So I stopped pretending and built the audio app directly.
Two years from now, some reading app may invest enough in audio to close this gap. Probably worth doing if their user base wants it. For now, the gap is real, and the audio-first answer is a separate product with the audio defaults baked in from the floor up.
What this means if you're choosing
A practical heuristic. When you imagine "catching up on newsletters this week," does the picture in your head involve a screen or earbuds?
- If the picture has a screen in it, a reading app is probably what you actually want. Meco is great. Substack's app is great. The Stoop folks have done good work. You don't need Junco.
- If the picture has earbuds in it, you're our person. Junco is built end-to-end for that mode and the difference shows up almost immediately.
Both answers are fine. Pick the one that matches your actual day.
If audio is your mode, join the Junco beta and we'll get you in as soon as we're on the App Store. And if you're a builder thinking about adding audio to a reading app, please do. The more places people can listen to good writing the better. Just go in knowing that "listen button" and "podcast app" are different products.