Prod Crate

Producers, engineers, and DJs accumulate very large audio libraries. Samples arrive from subscription services, from purchases, from collaborators, and from years of their own recording. Four things go wrong, and they compound.

Files live on laptops and external drives. Drives break, get lost, and get stolen, and years of work goes with them. There is usually no backup, because backing up a library measured in terabytes is its own project.

Samples arrive from many sources with no consistent naming. A library assembled from a dozen origins carries a dozen naming conventions, which means nothing can be found later without already knowing where it is.

Project files break when a referenced sample moves or gets deleted. Opening an old session and finding it silent is common enough that people avoid reorganizing their libraries at all, which guarantees the disorder keeps growing.

Collaboration means emailing large files back and forth, or compressing them until they are no longer worth sending.

Each of these takes time away from the work the user actually wants to do. Organization is a tax on making music, and it is paid by people who never chose to become librarians.

The tax also compounds in a way that punishes experience. The longer someone works, the larger their library, the worse the retrieval problem, and the more valuable the material they cannot find.

Cloud storage mounted as a local drive. Creators keep the workflow they already have while the library sits somewhere that does not fail when hardware does. I chose S3 for durability and for cost at the sizes these libraries reach. A consumer sync service would have been faster to build against and would have capped out well below what this user needs.

AI-driven sorting. Files from every source land under consistent rules, so samples stay findable and projects stop breaking on missing assets. The rules do the work a person would otherwise do by hand and, in practice, put off indefinitely.

Shared cloud access. Collaborators reach files directly instead of emailing them.

Lossless audio storage. Quality is not negotiable for this user, and a product that quietly degrades audio to save storage would be rejected on the first listen.

Deferred on purpose: accounts, mobile clients, and lossless playback. Each of those is real work, and none of it matters if the core workflow of mounting, sorting, and retrieving does not hold up. Building them now would mean maintaining features around a workflow that might still change.

This is pre-launch. There are no users beyond me. I am validating the workflow on a working build that runs against my own library before productizing any of it.

Building for a user I am gives me fast feedback and one bad habit. I am the easiest user in the world to satisfy, because I already know where everything is and I designed the rules around how I work. Nothing here is validated until someone else's library is on it.

The first outside users decide three things I cannot decide for myself.

Whether the sorting rules hold up against a library assembled by someone with different habits and a different vocabulary for their own files. My naming instincts are baked into the current rules and I cannot see where.

Whether cloud storage mounted as a local drive is fast enough for people working in a session in real time. Latency I tolerate while testing is not the same as latency someone tolerates mid-take.

And whether this is worth paying for. The problem is clearly annoying. Annoying and expensive are different things, and only the second one supports a product.