Building a podcast player for active learning
Podcasts are great at exposing you to ideas, but terrible at making them stick.
Most listening happens while commuting, training or doing chores. Your attention drifts. You miss something important. You rewind 30 seconds. You tell yourself you’ll revisit the episode later. Sometimes you do, but usually you don’t.
I noticed this most with information-dense podcasts like Huberman Lab. Even with my endless rewinding, there was still this feeling I’d only half absorbed the material.
That felt like a product gap.
I started wondering what a podcast player would look like if it were designed not just for consumption, but for retention.
The idea
The core idea behind Grokast is simple: break episodes into chapters and build a loop around each one:
- Listen
- Reflect
- Retrieve
- Continue
At the end of a chapter, playback pauses, and the app presents a small set of choices:
- Write a takeaway
- Take a quiz
- Replay the chapter
- Continue to the next chapter.
That small interruption is the core of the product.
Instead of drifting through an episode, the app asks you to do something with what you just heard.
Designing the learning loop
The takeaway flow is intentionally lightweight. The goal is not polished notes, but rather to turn “I kind of got that” into something explicit.
The quiz flow serves a different purpose: retrieval practice. According to Huberman, testing yourself on material you were just exposed to improves retention by ~50%.
If you do well on the quiz, the primary action becomes “Next chapter”, and if you struggle, “Replay chapter”.
What I chose not to build
A lot of what I’m proudest of in Grokast is not what I’ve built, but what I’ve chosen not to build yet.
Grokast still has no auth. User data, like takeaways and quiz progress, is stored locally in IndexedDB. For now, local-only was the right trade-off because it let me put something in the user’s hands sooner and gather feedback. If the product earns it, I can add cross-device sync later.
Grokast still has no desktop-specific styles. Most people listen to podcasts on their phones, so it makes sense to focus entirely on building an awesome mobile experience first. Working this way has the added benefit of forcing better decisions: on a small screen, every extra action and every weak feature becomes obvious.
You also cannot search for and play any episode you want. Grokast currently automatically adds new episodes from a small set of popular shows. Those shows have enough listeners for me to validate the idea without taking on the complexity and cost of opening the product to arbitrary podcast ingestion.
It’s easy to feel productive building the perimeter of a product: auth, multi-device support, search. They may become real requirements eventually, but right now, they’re simply convenient places to hide from the harder question:
Does the actual product experience feel valuable?
For Grokast, the most important thing to validate was the learning loop itself.
I would rather have a narrow product with a strong core than a broad product with a weak one.
Earning complexity
Grokast evolved by following bottlenecks.
The first version had a single hardcoded episode. That was enough to test the learning loop with friends and family.
But if I learned anything from watching The X Factor as a kid, it’s that feedback from friends and family has limits, so I started sharing recent episodes on relevant podcast subreddits.
Adding episodes by hand was too slow, so I wrote a script I could run locally that used AI APIs to transcribe episodes, identify chapter boundaries and generate quiz questions.
Once I had confirmed the idea resonated with people, the next question was whether they would keep using it. To answer that, I needed new content to keep appearing on Grokast.
Only then did a cloud-based episode processing pipeline make sense, so I built one on Cloudflare.
Rendering diagram...
What I learned about distribution
Building Grokast was a lot easier than answering the question that matters most: do enough people want this badly enough to keep using it?
Posting on X taught me very little. Almost nobody responded.
Reddit was better. The strongest early response came from Modern Wisdom listeners, who immediately understood the idea and gave useful feedback. One commenter felt the quizzes had too many questions and should focus more on applying ideas rather than recalling them. That directly influenced the generation pipeline.
const listenerGoal = await inferListenerGoal(episode)
const questions = await generateQuestionsForGoal(episode, listenerGoal)
But useful feedback is not the same as proof of demand.
This is where the project still feels unresolved. The question now is not whether I can build Grokast. It is whether people actually want an active podcast-listening experience or would prefer a passive one.
The journey ahead
For most of my career, I have focused on building software. Grokast made me realise that if I ever want to build something people actually use, that is only half the job.
As Naval Ravikant put it:
Learn to sell. Learn to build. If you can do both, you will be unstoppable.
I know how to build. Now it’s time to learn how to sell.