How One Brutal Email Fixed Everything Wrong With My Audiobook Converter
A solo developer's journey from broken features to actually listening
Building software alone creates blind spots you didn't even know existed. You think you know what works. You document features before building them because you're excited about where the software could go. You ship things that technically compile and run but don't actually solve problems real people face. Then someone sends you the truth wrapped in a detailed email, and everything changes.
This is that story.
The Email That Changed Everything
Two weeks ago, a user named Paul sent me an email. It wasn't a quick "hey this is broken" note you can dismiss. It was a full audit. He went line by line through my help documentation for ChapterForge (my MP3 to M4B audiobook converter), calling out every feature that either didn't work or didn't exist at all.
He'd write things like "Drag and drop simply drag MP3 files or folders" next to my documentation. Then he'd add in all caps "CANNOT DO THIS." Next line, "Click the Add Files button" from my instructions. His response? "THERE IS NO ADD FILES BUTTON." My personal favorite was "Reorder chapters by dragging." His finding? "The hand appears when hovering but produces nothing at all."
Each feature promise got followed by either "THIS WORKS" or "CANNOT DO THIS." The pattern became clear pretty fast. I'd documented a bunch of features I wanted to build, then I'd never actually built them. Or I'd built them halfway and convinced myself that counted.
The embarrassment hit immediately. This wasn't a bug report you fix and move on from. This was proof I'd shipped vaporware documentation while the actual app limped along half-functional. Every "CANNOT DO THIS" was evidence I'd failed at the most basic level (making software that does what it claims to do).
What Was Actually Broken
Here's the honest inventory of what didn't work.
I'd written code for drag and drop months ago. The code conflicted with other features, so I disabled it "temporarily" while I figured out the issue. "Temporarily" became permanent because I moved on to other things. I forgot to remove it from the docs because who rereads their own documentation?
The Add Files button got documented extensively. I wrote detailed instructions about clicking it and selecting files. I included descriptions of where it lived in the toolbar. The button never existed. I'd planned it, written about it as if it was real, then never implemented it. Just... forgot to make the thing I'd already documented.
Chapter reordering might've been the worst offender. The visual handle appeared when you hovered over chapters. You could grab it with your mouse, feel the cursor change to the drag cursor, get that little dopamine hit of visual feedback. Then click and drag produced absolutely nothing. Just visual theater with zero underlying function. I'd built enough interface to fake it without actually making it work.
Audio preview was another complete fiction. The help file promised you could preview audio content before converting. You cannot preview audio content. You've never been able to preview audio content in any version I've shipped. I documented a feature I thought would be cool someday without building it first. Aspirational documentation meeting disappointing reality.
Then there were the advanced settings Paul pointed out. Custom bitrate, sample rate configuration, concurrent job limits, all documented in the settings section with explanations of what each one does. None actually present in the settings page. Just words on a help page pointing to empty interface elements. It's like writing a recipe for a dish you've never cooked.
The pattern was brutally clear. I got excited about features, documented them as if they existed (because writing is easier than coding), then either forgot to build them or built them wrong and moved on.
Paul's Response Changed My Approach
I sent Paul a long apology explaining what happened and promising fixes. I expected him to uninstall and never respond. Most people would. You discover software is half-broken, you move on to something that actually works. Instead, he responded with clarity that completely reframed my priorities.
He didn't need some of those features. Audio preview? Not critical for his workflow. MP3 splitting for subdividing long files into chapters? Would be nice eventually, but he could work around it for now using other tools. Two-stage conversion settings? Just explain how it works in the docs, no need to expose complex controls most people won't understand anyway.
That clarity freed me from feature anxiety. Instead of trying to build every documented feature in some heroic coding marathon, I could focus on fixing the core stuff that should have worked from day one. The features people actually use daily. The basics that make or break whether someone keeps using your software or uninstalls it after ten frustrated minutes.
Things like drag and drop working properly when you drop files into the window. Chapter reordering functioning when you grab that handle instead of mocking you with fake interaction. A file picker button that actually exists when you click where the docs say it should be. Settings pages that match what the documentation promises.
Paul gave me permission to stop chasing shiny features and fix the foundation. Sometimes that's what you need. Someone telling you it's okay to do less, as long as what you do actually works.
Two Weeks of Focused Fixes
I stopped planning new features. I started shipping fixes instead.
Drag and drop got rewritten from scratch. Files and folders both work now. You drop them into the project view, they import correctly with proper metadata scanning. I tested it with single files, multiple files, nested folders with dozens of MP3s. It works. Not "works in theory" or "should work eventually" but actually, demonstrably works right now.
Chapter reordering got the attention it deserved from the beginning. I fixed the drag handle functionality completely. You grab it, you drag up or down, chapters reorder in real time with smooth animation. The visual feedback now connects to actual logic underneath doing the work. Should've worked this way from the start, but at least it works this way now.
The Add Files button finally got built and added to the project view toolbar. You click it, a proper file picker opens, you select individual files or multiple files at once. The button I'd documented but never created now exists and functions exactly as the help file always claimed it did.
Custom bitrate and sample rate settings made their way into the actual settings page. Paul specifically requested configurable bitrate, and sample rate came up during testing as another common need. Both settings now exist with proper validation so you can't accidentally set something that'll break the conversion.
The concurrent jobs setting moved from being buried in the queue view (where only power users stumbled across it) to the main settings page. Better visibility, easier to configure, makes more sense living with other global settings.
Then came the help documentation overhaul. I removed every feature that doesn't exist. I rewrote workflows to match the actual UI. No more promising vaporware or aspirational features. Simple rule that should've guided me from the beginning (if it's documented, it works; if it doesn't work yet, it's not in the docs).
Version 1.0.9.1 shipped to Microsoft Store with seven fixes in two weeks. Not promises or roadmap items or "coming soon" disclaimers. Actual working features you can use today.
Taking It to Reddit
I figured the transparency might resonate beyond just Paul. Why not share the whole story? User sent brutal feedback, I fixed everything in two weeks, here's what happened and what I learned. I wrote it up and posted to r/audiobooks first since that's where people actually care about converting MP3 collections into organized audiobooks.
The response surprised me in good ways.
People appreciated the honesty. Solo developer admitting mistakes and shipping fixes fast apparently stands out in a world where corporate software takes six months to acknowledge bug reports. Comments rolled in with questions, suggestions, and way more technical feedback than I expected from what I thought would be a casual audience.
Some comments were supportive and encouraging. Others pointed out I was comparing ChapterForge to paid tools while completely ignoring free alternatives like AudioBookConverter on GitHub (fair criticism). I adjusted my framing in responses, acknowledged the free options exist and work well, explained ChapterForge serves people who want GUI simplicity over command-line power. Different tools for different users with different comfort levels.
Then came the really technical questions that made me think harder.
Reddit's Technical Deep Dive
One user posted ten detailed technical questions exposing more limitations I hadn't fully considered. The kind of questions that come from someone who actually understands audiobook encoding at a level deeper than "FFmpeg makes it work somehow."
They asked about lossy to lossy codec conversion with no lossless bridge in between. Yes, that's what happens (MP3 to AAC in single pass). I had to acknowledge this means quality loss for audiophiles starting with already-compressed sources. Not ideal for everyone, but it's optimized for speed over preserving maximum quality from lossy inputs.
What chapter format gets used by default? QuickTime format, which is the standard M4B approach. It works with Apple Books, Plex, and most modern audiobook players. Should've stated this clearly in documentation instead of assuming everyone knows.
Does the software convert between Nero and QuickTime chapter formats? No, it doesn't. ChapterForge creates new M4Bs from source audio files, it doesn't modify existing chapter metadata in already-encoded files. Another limitation I should document clearly instead of hoping nobody notices or asks.
If input files are already M4A format (which is already AAC), will the software just concatenate them or re-encode everything? Currently it re-encodes everything regardless of input format. This is genuinely stupid and wasteful. It should detect AAC input at acceptable bitrate and just concatenate without re-encoding. Adding this to the roadmap because it's embarrassing it wasn't there from the start.
Do you show bitrate and sample rate per input file in columns like other audio tools? Not implemented currently. Would help power users verify file specs before conversion starts. Good UI enhancement that serves advanced users without cluttering the interface for casual users who just want to click convert and walk away.
Every question exposed either a limitation I need to fix or a gap I need to document honestly. This is the kind of feedback I should've been asking myself during development instead of assuming I knew what mattered.
The Pattern Becomes Clear
Building alone creates blind spots you can't see from inside your own perspective. You make assumptions about what matters based on your own workflow and your own use cases. You document aspirations instead of reality because you're excited about where the software could eventually go. You ship things that technically compile and run but don't solve actual problems people face when they sit down to organize their audiobook collection.
Paul's detailed audit forced me to see the gap between documentation and reality. Every "CANNOT DO THIS" next to a documented feature was proof I'd been building in a vacuum without external feedback. Reddit's technical questions exposed assumptions I'd made without questioning them (like "obviously I should re-encode everything" which turns out to be obviously wrong when someone who knows better asks about it).
Both sources taught me the same lesson through different approaches. Listen first to what people actually need. Build second based on that understanding. Document third to match what you actually built. The order matters way more than I realized when I started this project.
What I'm Building Next
Here's what's coming, based on actual user requests instead of my assumptions about cool features nobody asked for.
Multiple people asked for MP3 splitting capability. You'd import one long MP3 file, subdivide it into chapters manually by setting timestamps, then export as a single M4B with proper chapter markers. Sounds simple until you think through the details properly. It needs validation logic so you can't set chapter times that overlap or extend past the audio end. It ideally needs audio preview so you can confirm chapter start times are correct before spending time converting. I'm not rushing this one because doing it half-functional defeats the entire purpose. Q1 2026 timeline if development goes smoothly and nothing breaks along the way.
Smart AAC detection needs to happen soon. If your input files are already AAC format at acceptable bitrate, the software should just concatenate them without re-encoding. Saves quality loss and saves processing time. Should've built this from the start honestly, it's kind of embarrassing it wasn't there (thanks to the Reddit user for pointing this out).
Bitrate and sample rate column display came up multiple times in different contexts. Power users want to see input file specifications before conversion starts. It helps catch mismatched files early in the workflow. Good UI addition that serves advanced users without cluttering the interface for people who don't care about technical details.
Better metadata handling documentation is coming soon. I need to clearly explain what metadata gets preserved versus stripped during the conversion process. Compatibility matters a lot for people building large libraries they expect to use for years.
Chapter format limitations need to be stated clearly up front in the documentation. Not everyone needs Nero to QuickTime conversion capability, but people should know ChapterForge only outputs QuickTime format M4B files before they spend time organizing complex projects. Prevents surprises and frustrated users discovering limitations after investing effort.
What Actually Works Now
Version 1.0.9.1 shipped with working implementations, not promises or aspirational roadmap items.
Drag and drop functions properly for both files and folders now. Just drop them in the window, they import with metadata scanning. Chapter reordering works when you grab the handle and drag up or down. No more fake interaction theater pretending to work. The Add Files button exists in the toolbar and opens a proper file picker that actually functions. Custom bitrate and sample rate settings are fully configurable in the settings page where you'd expect to find them. The concurrent jobs setting lives in the main settings page now for better visibility instead of hiding in the queue view where nobody found it.
The help documentation matches actual functionality completely now. Every workflow described actually works the way it's described in the docs. Novel concept, I know, but apparently important.
You can import MP3 folders and the app scans metadata automatically using intelligent logic. It maps Album tags to Title and Artist tags to Author because that's how most people tag their audiobook files in practice. Automatic cover art detection finds embedded artwork or folder images like cover.jpg and folder.png without you clicking anything. Single-pass FFmpeg conversion runs about 30% faster than traditional multi-pass approaches that read and write files multiple times unnecessarily. The batch queue includes crash recovery and persistence through reboots, so power outages or system crashes don't lose your conversion work.
Project and chapter level metadata editors work with bulk operations built right in. Auto-numbering lets you number chapters sequentially in about two seconds. Regex find and replace handles complex pattern matching across all chapters at once for power users. The propagate fields function copies common metadata across selected chapters instantly. Everything processes 100% locally on your machine with zero uploads to external servers, so your files stay completely under your control.
Everything listed here actually works right now. No aspirations, no "coming soon" disclaimers, no promises about future versions. Actual features shipping actual value you can use today.
The Honest Position
ChapterForge isn't the most advanced audiobook converter available on the market. Command-line tools like m4b-tool offer way more codec control and advanced features that power users legitimately need. Free tools exist that work really well for technical users who are comfortable with terminal commands and FFmpeg syntax.
ChapterForge serves people who want GUI-based editing without learning command-line tools or reading FFmpeg documentation. You get visual drag and drop for organizing files intuitively. You get bulk metadata operations with preview windows before applying changes. You get batch processing with queue management that survives crashes and reboots. Everything runs locally on your machine without uploads or cloud processing or accounts.
It's not trying to replace advanced tools for power users. It's serving different users with different workflows and different comfort levels with technology.
The Reddit user asking ten technical questions about codec handling probably uses m4b-tool already, and that's perfectly fine for their needs. ChapterForge isn't for everyone, and pretending otherwise would be dishonest marketing. But for people organizing podcast archives or audiobook collections without wanting to learn FFmpeg syntax and write shell scripts, it solves real problems they face when sitting down to organize their audio library.
Understanding that position helps me build better software. I'm not trying to compete with every tool in existence or be everything to everyone. Just building something genuinely useful for specific workflows and being honest about limitations instead of pretending they don't exist or hiding them in fine print.
What This Cost Me
It cost two weeks of evenings and weekends fixing features that honestly should have worked from the initial release. Time I could've spent building new features or marketing the app to get more users. Time spent rewriting documentation to match reality instead of aspiration, even when reality looked less impressive on paper. Mental energy dealing with the genuine embarrassment of shipping half-functional software and having someone document it line by line with receipts.
Worth every single minute though.
It's better to ship fixes based on honest feedback than keep building features nobody actually asked for or needs. It's better to document reality than aspiration, even when reality looks less impressive in marketing copy. It's better to serve actual users with real needs than imagined users in theoretical workflows you made up in your head.
Paul's audit hurt to read at first. Every "CANNOT DO THIS" felt like proof I'd failed at the most basic level. Reddit's technical questions exposed more gaps I hadn't considered or thought about deeply enough. Both sources made the software genuinely better in ways my solo development in a vacuum never would have achieved.
The Request
If you're converting audiobook MP3s on Windows and you're genuinely frustrated with expensive commercial tools or sketchy upload services that want your private files on their servers, try ChapterForge. It costs $9.99 one time purchase on the Microsoft Store. No monthly subscription trying to extract recurring revenue. You pay once, you own it completely, you get all future updates included.
If something's broken or missing features you actually need for your workflow, tell me specifically what's wrong. Be as detailed as Paul was with his line-by-line audit. That level of feedback gets real results you can see and use. Seven concrete fixes shipped in two weeks because one user took the time to document everything properly instead of just complaining vaguely and uninstalling.
If ChapterForge works well and saves you time organizing your audio collection, please leave a Microsoft Store review. Small apps from solo developers live or die on reviews because we don't have marketing budgets or PR teams. Honest feedback (whether positive or negative) helps other people understand what they're actually getting before they spend money.
More importantly, if you see gaps or have suggestions for improvements, speak up and share them. Reddit's technical questions pushed me to think way harder about codec handling and metadata scope than I had before. User requests for MP3 splitting moved that feature way up the priority list from "someday maybe" to "working on it now." Your feedback genuinely shapes development direction more than my assumptions about what's important ever could.
Where This Goes Next
I'm going to keep listening to feedback. Keep shipping fixes and improvements. Keep documenting reality instead of aspirational features I haven't built yet.
The technical user asking detailed questions about lossy-to-lossy conversion and chapter formats clearly knows more about audiobook encoding than I do. Learning from that expertise makes the software better for everyone using it. The casual user asking why there's no Add Files button exposed a documentation problem that was confusing literally everyone who read the help file and tried to follow the instructions.
Both types of feedback matter for different reasons. Both make ChapterForge more useful to more people with different needs and different skill levels.
Solo development gets genuinely lonely sometimes. It's easy to build in a vacuum, assume you know what matters based on your own use case, ship things that technically function but don't solve real problems people face. You can convince yourself you're being productive while actually building the wrong things for imaginary users. External feedback breaks that cycle and forces you to see what you're missing from inside your bubble.
Paul's detailed audit, Reddit's technical scrutiny, and ongoing user requests provide the external pressure needed to build something actually useful instead of just technically functional. There's a real difference between those two things, and that difference matters more than I understood when I started.
Try It Today
ChapterForge lives on the Microsoft Store right now. You can search "ChapterForge" or visit apps.microsoft.com/detail/9n44m266p5qf if you want the direct link. It's $9.99 one time purchase with no recurring subscription fees, no per-file processing charges, no cloud processing costs. It works on Windows 10 or Windows 11.
Try it out. Break it if you can. Tell me specifically what's wrong or what's missing for your workflow. Be detailed about what doesn't work the way you expected. Last time someone did exactly that, seven concrete fixes shipped in two weeks. That's the development cycle now (listen carefully, fix quickly, ship regularly, repeat continuously).
Software gets genuinely better when people care enough to document what's broken instead of just quietly uninstalling and moving on. I'm listening, I'm reading comments and emails, I'm responding to feedback. This isn't corporate software with a support ticket system that disappears into a black hole. It's one person building something useful and genuinely trying to get it right.
Your feedback actually matters here. Use it.
Anoop builds ChapterForge during evenings and weekends while working a day job in operations. He's still learning how to document features that actually exist instead of ones he wants to build someday. Feedback genuinely welcome at the Microsoft Store or Reddit, where he's probably reading comments right now instead of sleeping like a responsible adult.
