Here's the irony: ChapterForge for macOS was supposed to ship first.
I started building it on Mac over a year ago. A native Swift app to turn scattered MP3 files into properly structured M4B audiobooks, with chapters, metadata, and cover art. No cloud uploads, no friction, just local conversion that respects your files.
Then I got stuck. Features piled up. Architectural decisions paralyzed me. Months passed.
So I did something pragmatic: I rebuilt the core functionality for Windows, stripped down to essentials, and shipped it. That was three months ago. It worked. Users liked it. One user even sent detailed feedback on what they wanted changed.
That should have been my signal.
Instead, I came back to the Mac version determined to make it "better." Not just feature parity with Windows, but a complete ecosystem. iOS companion app. CloudKit sync. Remote conversion. The works.
Four months later, I'm writing this post about why I finally cut all of that to ship what I should have shipped a year ago.
How It Actually Started (and Went Wrong)
ChapterForge began as a focused Mac app. Import MP3 files, detect chapters, edit metadata, convert to M4B. Do everything locally and fast.
Then came the ideas.
What if projects sync automatically? What if an iOS app lets you trigger conversions remotely? What if you could play the finished audiobooks right there on your phone, with both MP3 album playback and proper audiobook controls? What if CloudKit handles real-time state across devices?
Honestly, it sounded like the right way to build on Apple platforms. Native. Integrated. The experience users expect.
In reality, it created three problems.
Architectural explosion. I started with iCloud Drive sync. Too slow. Actions would take forever, definitely not fast enough for any kind of responsive experience. So I moved to CloudKit for direct transaction-based messaging between iOS and macOS targets. That meant rewriting how state worked, how permissions flowed, how recovery happened when things failed.
Testing paralysis. The iOS app was working. The Mac app was working. Getting them to work together reliably was a different story. Sync would function but metadata wouldn't match. Jobs would resume but with stale state. I'd fix one integration bug and introduce two more.
Emotional fatigue. Around month three, a persistent CloudKit bug surfaced that needed serious analysis, probably another architectural redesign. That's when I realized: I was four months into rebuilding something I'd already shipped on Windows in a fraction of the time.
So here's the thing. I started reading Reddit threads about MVPs, about shipping, about founder paralysis. Not for motivation, but because I needed permission to stop.
The Wake-Up Call
The Windows version taught me something I ignored: users don't care about architectural elegance. They care whether the app solves their problem today.
One Windows user sent detailed feedback. Not about sync. Not about iOS integration. About the actual conversion features, the metadata handling, the batch processing workflow.
Nobody asked for the features I was building.
I was solving problems that didn't exist yet, for users I hadn't earned yet, on platforms I hadn't proven yet.
That's when the concept of MVP really clicked. Not as a compromise, but as a strategy.
The Reset: Going Back to What Worked
I went back to a branch from before the CloudKit migration, before the iOS integration work, before the ecosystem dreams.
This version of ChapterForge does exactly what the Windows version does, rebuilt properly for macOS. No sync. No iOS app. No speculative features.
And critically: conversion works, permissions are predictable, UI state reflects reality, jobs finish reliably, errors are understandable.
In other words, it respects the user's time.
What ChapterForge Does Today (Intentionally)
This launch version focuses on one job: take messy audio files and turn them into a proper audiobook.
Local-only processing (no uploads, no accounts). Folder-based MP3 import. Chapter-level metadata editing. Cover art handling. Fast single-pass FFmpeg conversion. Reliable batch processing, which is honestly the feature I'm most proud of technically.
Everything that made the Windows version useful, now native on macOS. Nothing more. Nothing hidden behind "coming soon."
What About Those Other Features?
They're not dead. They're deferred.
The iOS app with its MP3 album player and audiobook player. The remote conversion capability. The CloudKit sync. They all make sense, but only after this foundation proves itself.
Here's what I learned the hard way: I built a working iOS app for an unreleased Mac app. That's backward. Users don't care about companion apps when the main app doesn't exist yet.
If ChapterForge for Mac gets real traction, those features become obvious next steps. If it doesn't, I'll have saved months of continued work on things nobody wanted.
That realization hurt, then brought relief. I made the right decision.
Lessons I'm Taking Forward (Because This Was New Territory)
I've never done this before. Cut features to ship, I mean. It reshaped how I think about building software.
Architecture should serve shipping, not curiosity. Moving from iCloud Drive to CloudKit made technical sense. It didn't make shipping sense.
Speculative features are liabilities. Until a user asks for it, it's just unvalidated complexity. Nobody requested the iOS app. I built it anyway.
Solo development at night and on weekends demands ruthless focus. I don't have the luxury of exploring architectural possibilities. I have limited hours and limited energy. They need to go toward things that ship.
User feedback beats internal vision. The one Windows user who sent detailed feedback taught me more about what matters than four months of feature planning.
Momentum comes from release, not readiness. Real feedback only exists after launch.
What Happens Next
ChapterForge will evolve, but only after Mac users tell me what matters.
The iOS app, the sync capabilities, the remote features. They're all possible. But they're not next. Next is listening.
This launch isn't the end of development. It's the beginning of learning what actually needs to be built.
Final Thought (What I'd Tell Myself Four Months Ago)
Ship fast with a working version. Get user feedback first, then add new features. What we think users want may not be what they actually want.
That's advice I should have followed a year ago. That's advice I'm following now.
If you're building something and feel stuck polishing edges no one has touched yet, planning features no one requested, building infrastructure for apps that don't exist, this is your sign.
Ship the version that works. Let users teach you what's worth building next.
That's what I'm doing with ChapterForge for macOS.
Ready to Try ChapterForge?
ChapterForge for macOS is now available. It does one thing well: converts your MP3 files into properly structured M4B audiobooks with chapters, metadata, and cover art. All processing happens locally on your Mac.
No cloud uploads. No account required. No feature bloat.
Download ChapterForge for macOS →
Already using the Windows version? I'd love to hear what you think about the Mac version.
Have feedback or feature requests? Email me or join the discussion on Reddit. Your input directly shapes what gets built next.
