How Listener Feedback Turned Bloox Into a Better Audiobook App in Two Months

A couple of months ago, I posted my side project in front of audiobook listeners and basically asked them to tell me what was wrong with it.

This is one of those things that sounds very normal when you say it quickly.

In practice, it means strangers get to look at something you have spent nights and weekends building and say things like: nice, but why can’t I import from Audiobookshelf? Where are bookmarks? Why does this import fail? Can I use my Audible library? Why is there no widget? What about CarPlay?

And the annoying part is that a lot of them were right.

I had already built Bloox around a few ideas I cared about: on-device transcription, “What Did I Miss?” recaps, character help, privacy, no ads, no subscription. But once real audiobook listeners started using it, the gaps became much more practical.

People did not send me a neat feature plan. They sent comments, bug reports, screenshots, direct messages, App Store reviews, and half-formed wishes. I preferred that. A polished plan would have been too tidy. The messy version told me where the app was getting in people’s way.

The request is rarely the full feature. It is usually the first clue.

The feedback channels were messy, which was the point

I did not get feedback from one place.

Reddit was useful because people are direct. Sometimes very direct. App Store reviews were useful because they came from people who had already gone through the real public install path. Direct messages were useful because people would explain their exact library setup, which is almost always weirder than the one you imagined. Friends and family were useful because they would say things like “I don’t understand what this screen wants from me,” and then look at me as if this should have been obvious.

I also added feedback opportunities inside the app. Not everywhere. I hate apps that constantly ask how they are doing. But some moments are worth asking about. If someone just finished a Wi-Fi upload, I want to know if the upload made sense. If someone gets a Book Chat answer, I want to know if it actually helped.

Those are different signals:

• Public forums showed repeated needs and the vocabulary real listeners use.
• App Store reviews showed what survived the full release funnel.
• Direct messages gave me the details behind the short public comments.
• Friends and family caught confusing flows before I embarrassed myself more widely.
• In-app prompts told me whether a new flow worked at the moment someone actually used it.

Then I looked for repeats.

One person asking for something can be interesting. Three unrelated people asking for the same thing in different words is harder to ignore. Ten people asking for the same thing means I should probably stop being clever and build it.

“You need to support importing from X”

This was by far the loudest category.

At first, Bloox was much more of a file-based audiobook player. If you had an M4B or MP3 file, great. If it was in iCloud or Google Drive, also great. But audiobook people have wildly different library setups. Some self-host with Audiobookshelf. Some use Libation. Some have local folders. Some buy everything from Audible. Some have a heroic, possibly cursed, folder of old CD rips.

The request sounded simple: import from more places.

The actual decision was broader: Bloox should meet the library you already have, not force you to rebuild it just to try the app.

So Bloox grew import paths: local files, iCloud, Google Drive, local Wi-Fi upload through a browser, Audiobookshelf, and direct Audible import.

Some of that is not glamorous. Wi-Fi upload is not a science project. But it removes a real annoyance. Not every feature has to be magical. Sometimes the right thing is to make the obvious flow work without asking the user to become a part-time file manager.

Audible import was different.

People liked the idea of Bloox, but many already had large Audible libraries. My first answer was technically correct: use Libation. It is a great desktop tool, and I still recommend it. But for someone who just wanted to try Bloox with a book they already bought, it was too much ceremony.

So I built direct Audible import. You sign in on Amazon’s hosted page, choose a book, and Bloox downloads and converts it on-device. It is US-only in v1, one book at a time, and unofficial. Still, it changed the pitch from “this is useful if you already have files” to “try Bloox with the library you already own.”

“I want to chat with my book”

This was one of those requests that felt obvious about five seconds after someone said it.

Bloox already had “What Did I Miss?”, which generates an on-device recap when your attention drifts. But a recap chooses the question for you. Sometimes you do not need a summary. You need to ask, “Is this the same person from two chapters ago?” or “Are we still in the castle?” or “Why is everyone angry at this guy?”

That became Book Chat.

The key was spoiler boundaries. A generic chatbot can talk about a book, but it can also casually ruin the next 300 pages. Bloox knows what you have heard so far, so Book Chat is grounded in that context rather than the entire book.

It is also honest about privacy. Transcription and recap summaries run on-device. Book Chat is optional and sends your question plus relevant heard-so-far context to Bloox servers after consent, because long-context chat is not good enough on-device yet.

“I want bookmarks” is not a spec

I did not personally use bookmarks much.

Not using a feature myself is not a good enough reason to skip it. Several users asked for bookmarks, and the pattern was clear enough that I needed to build them.

But simply adding a timestamp list felt underwhelming. Other apps already do that. Bloox had a transcript. It had on-device AI. It knew what was happening around the moment you saved.

So the feature became smart bookmarks.

When you bookmark a moment, Bloox can add a short on-device summary of the context around that point. For fiction, that means what was happening in the scene. For non-fiction, it can behave more like a note about the idea being discussed.

If I had implemented the literal request, the app would have gained a timestamp list. Fine, but not very Bloox. The transcript gave me a better version of the same idea: save the moment, and also remember why that moment mattered.

“I want a widget”

I was skeptical.

My experience with widgets is that many people like the idea of them and then forget they exist. But enough people asked, so I built one anyway. The question was how to make it worth the space on someone’s home screen.

The obvious widget resumes playback.

The Bloox widget also uses the app’s on-device summary ability. When it is idle, it can show a short catch-up on where you left off, so returning to a book is not just one tap away, but mentally easier too.

The same set of comments also led to smart rewind. People wanted the app to recover from interruptions: a Siri notification, a pause, a break, the ordinary chaos around listening. So Bloox now rewinds a configurable short amount after interruptions and a longer amount after an extended pause.

The feature request was a widget. The thing I really wanted to fix was the moment when you come back to a book and need three minutes just to remember where you are.

The small requests were not small

Some requests were large: Audible import, Audiobookshelf, Book Chat, iPad redesign, CarPlay.

But the smaller ones taught me just as much.

Someone wanted a sleep timer snooze. The straightforward implementation would be a button that adds time. Bloox has that now, but it also plays a soft chime one minute before the timer ends. I added that after thinking about the actual situation: you might be half asleep, deciding whether to continue, and not exactly in the mood to negotiate with a UI.

Someone said the lock-screen scrubber caused accidental location jumps while the phone was in a pocket. Not glamorous, but exactly the kind of bug that can ruin trust. So I disabled the risky behavior.

Someone wanted custom playback speed. Not just the usual steps. A favorite exact speed. So now you can set the weirdly specific pace that your brain likes.

Someone wanted to toggle between time left in chapter and time left in book. One person. Still a good idea. Small, clear, useful, cheap enough to ship. It went in.

Someone wanted better iPad support. That one was not cheap. It forced a broader design-system pass so panels, pop-ups, settings, transcription, and Book Chat used proper reading widths instead of looking like an iPhone screen got lost on a bigger device.

A one-line comment can turn into a one-hour fix, a two-day feature, or a full redesign. You do not know which one until you actually chase it down.

Bug reports are product feedback too

Not all feedback is about new features.

Some of the most valuable messages were simply: import failed.

MP3 imports, M4B imports, Files app edge cases, weird file layouts, old CD rips, names with numbering patterns that look obvious to a human and ridiculous to a parser. Those reports improved the app for everyone because they exposed real-world data I would not have invented in testing.

Detailed bug reports are gold. They are not glamorous. They do not produce a shiny marketing bullet by themselves. But they tell you whether the foundation is strong enough for the exciting features to matter.

The best Book Chat experience in the world does not help if the user cannot import the book.

One feature did not come from users

Most of the recent work came from direct feedback.

The X-Ray-style character feature did not, at least not directly.

I built it after noticing what Bloox could do that other audiobook players could not. Once the app had transcript context and a character system, it could show spoiler-free character bios, highlight names in the live transcript, and show who appears in a chapter. This requires an explicit server permission because the character extraction is not fully on-device, but the idea came from the app’s unique capabilities rather than a direct request.

I like that balance. User feedback shaped most of what I built, but it did not replace judgment. People are very good at telling you what hurts. It is still your job to notice what became possible because of the thing you already built.

The feedback loop changed the backlog

I do not treat every request equally.

A backlog is not a democracy where every idea gets one vote and the most requested thing automatically wins. Some requests are repeated. Some unlock new users. Some make the app more reliable. Some are small enough that the right answer is just to ship them. Some need to wait because the privacy, technical, or UX tradeoffs are not ready.

What changed over these two months is that the backlog became much less theoretical.

It was grounded in real workflows:

• People with large Audible libraries who wanted Bloox features without rebuilding their library from scratch.
• Audiobookshelf users who wanted to try the AI layer on selected books.
• Listeners who fall asleep and need a graceful way back into the story.
• Users with messy multi-file books who needed imports to be resilient.
• People who wanted bookmarks, but really needed context around why they saved a moment.
• iPad users who expected the app to feel native on the device they actually use.

I would not have made as useful a backlog alone.

Fast shipping only helps if you are pointed somewhere useful

I am proud of the pace. In about two months as a side project, Bloox gained a lot: six import paths, direct Audible import, Audiobookshelf, Book Chat, smart bookmarks, a resume widget, listening insights, sleep timer refinements, custom speed, better import reliability, iPad polish, CarPlay, and more.

Shipping fast is fun, but only if you are not just sprinting in a circle.

The feedback helped me aim. Not because the community designed the app for me, but because it made the weak spots obvious. My job was to listen, decide what was worth doing, make the tradeoffs, build quickly, and then ask again.

That last part is easy to skip. After shipping a feature, you want to declare victory and move on. But a feature can satisfy the wording of a request and still miss the problem behind it.

So Bloox now asks for feedback at critical points. After a Wi-Fi import. After a Book Chat answer. Around moments where the user can still remember what happened and whether it worked.

I want feedback to be part of the product, not a ritual I do once every few months when I remember to be humble.

What I am taking from this

I am not pretending this is a grand universal theory of product development.

It is just what happened when I talked to the people using the thing, kept the feedback channels open, and tried to respond quickly without turning the app into a pile of unrelated requests.

The trick is not building every requested feature. Doing that would be chaos, and also probably a terrible settings screen.

The trick is hearing the request and asking what problem is hiding inside it.

“I want bookmarks” can mean “help me remember why this moment mattered.”

“I want a widget” can mean “help me resume without mentally reconstructing the last chapter.”

“I want Audible support” can mean “do not make me reorganize years of purchases before I can even try your app.”

“I want a sleep timer snooze” can mean “please design for me when I am half asleep and not at my finest.”

Honestly, this has been the most fun part of building Bloox. Every thoughtful complaint, weird edge case, and tiny suggestion makes the app less like something I imagined alone and more like something shaped by the people who actually listen.

Want the deeper build stories? Read how I built Book Chat or why I added direct Audible import.