It is very easy for recording features to sprawl. The moment an app can monitor an input and write audio to disk, the horizon starts expanding: waveform editing, click repair, EQ, side-by-side takes, mastering chains, and every other piece of studio logic that already has entire categories of software devoted to it. I have been trying quite hard not to let Kanora wander down that path.
That is not because those tools are uninteresting. It is because the actual job Kanora needs to do is narrower and, I think, more useful. The goal is to let someone capture a record, a cassette, or another live source cleanly enough that it can join the rest of the library without drama. Monitor the input, record the take, annotate it while the context is fresh, import it into the collection, and move on. That is a very different ambition from becoming a general-purpose production app, and I think the distinction is healthy.
The implementation has been guided by that boundary from the start. The recording service is built around a fairly plain flow: AVAudioEngine taps for capture, a dedicated recordings directory, conversion where needed, then an import step that places the result into the library properly instead of marooning it in a temporary corner of the filesystem. That last step is what keeps the feature attached to the rest of the app rather than becoming a novelty panel. The success condition is not “a file exists.” It is “this now feels like part of the same collection as my ripped CDs and imported albums.”
That boundary has helped with product decisions too. A lot of software earns complexity simply by being capable of it. Kanora has to be more selective. If the choice is between adding one more bit of surface-level recording polish and making the import path more trustworthy, I will take the import path every time. The audience for this feature is not asking for a DAW they can happen to rip records with. They are asking for library software that understands live sources well enough to preserve them properly.
This is a place where physical media matters without needing to be fetishised. Records and tapes create their own kind of urgency. They are finite, they are contextual, and in some cases the exact copy on your shelf is the thing that matters, not a generic album abstraction available in a catalogue somewhere else. If you have a pressing that sounds a particular way, a cassette someone made for you, or a hard-to-find source you simply want to keep, the software should help you preserve it without asking you to become a part-time audio engineer.
AI has been useful here mostly in helping me keep the scope honest. Feature work like this is prone to “while we’re here” drift, especially when the tooling makes exploration cheap. It is easy to imagine five adjacent capabilities and start treating them as a single coherent roadmap just because they all touch audio input. The more useful pattern has been to write down the actual user story, challenge the hidden assumptions, and keep asking whether the next idea strengthens the library workflow or merely makes the feature feel bigger. Sometimes AI is helpful precisely because it gives you enough distance to notice where you are starting to overbuild.
The outcome I want is fairly modest. I want someone to be able to route a physical source through Kanora, capture it, name it sensibly, and see it land on the shelf in a form they recognise. If that sounds less exciting than a mini recording studio, that is probably a good sign. It means the feature is still serving the app instead of trying to become its own product. There is enough software in the world already that confuses a broad list of capabilities with a clear reason to exist.