We Researched the Feature Everyone Asks For
Every product has one: the feature that every user asks for, that sounds obvious, and that the roadmap keeps almost absorbing. For Stem Shovel, our browser-based music collaboration tool, it is storing the DAW sessions behind the stems. A band uploads stems of a song; the Logic or Ableton or Pro Tools project that produced those stems is sitting right there on someone's laptop, one disk failure away from gone. "Can you keep the session too, and sync it?" is the most natural request in the world.
We did not build it. We researched it first, and the research document now sits in the repository with a status line we are proud of: research only, nothing built. This post is about what the research found, and about why writing the refusal down was worth more than the feature.
The Feature is Bigger than it Sounds
A DAW project is a small document plus a folder of audio, and the audio is what makes it heavy. An ordinary session runs 500 MB to 10 GB, which is ten to a hundred times the size of its stems. Worse, projects are not self-contained. Ableton and FL Studio reference samples outside the project folder; Logic can reference external audio and also keeps audio in the package after its regions are deleted. A copy made without the DAW's own collect step is often incomplete, and a backup that restores with missing files is worse than no backup at all.
So the simple ask ("keep my session") hides a format problem per DAW, a consistency problem per copy, and a trust problem per restore. Restore is the product. Nobody pays for upload.
The Graveyard Tells Stories
The research then looked at who had tried. Splice Studio ran from 2014 to 2023: a free desktop agent that watched your project folder, uploaded on every save, and kept every version, across Live, Logic, FL, GarageBand and Studio One. Splice shut it down, saying they had not "been able to provide the quality of experience of which we can be proud." The engineering lived in the agent and the per-format handling, and it was never paid for.
The survivors share a shape. Avid syncs Pro Tools sessions because Avid owns the Pro Tools format, and even then it shares at the track level rather than syncing files. Ableton Cloud syncs only small Sets and says plainly it is for synchronization, not storage. The third parties that live (Satellite Sessions, SyncMuse) sidestep the project file entirely and move audio instead. The pattern was clean enough to state as a rule: everyone who owns a DAW syncs its own format and keeps it small; everyone who does not either moves audio instead of projects or died trying. No third party syncs arbitrary DAW projects well today.
The Cost / Benefit Analysis
Here is the part that made the research worth doing: storage, the part that sounds expensive, is nearly free. Holding a 2 GB project for a year costs us about 55 cents on the blob store we already use, and 36 cents on a store with free egress. A band keeping twenty projects costs us about eleven dollars a year, seven on the cheaper store. Against market prices (Avid at 50 cents per gigabyte-month, Dropbox at about $6 per terabyte-month), a modest paid tier would clear its storage cost several times over.
So the economics inverted the feature. The expensive half of "store and sync" is not storage, which we assumed, but sync, which requires a desktop agent (a second product to build, sign, ship and support), format-aware code per DAW, and an answer for two people opening one session, which is a conflict and not a merge. That is the half that consumed Splice. The cheap half is the archive: accept a project folder in the browser, version it, hash the contents so unchanged audio is stored once, and stream a zip back on restore.
What We Shipped
The document ends with a recommendation, not a feature: offer paid project archiving with version history, priced by the gigabyte, built after billing exists, and revisit true sync only if archive customers ask for it. The product gets the version of the idea that a band actually needs (the session that made the stems, kept beside them, with a note that says "mix v3, before the bridge edit") and skips the version that has a graveyard.
That recommendation has already survived two roadmap debates, which is the real point. A feature request this popular comes back every few weeks, and each time, the answer is not a memory of a hallway conversation. It is a dated document with the prices, the failures by name, and the conditions under which we would change our minds. We wrote about structure as an economic asset and about how this project grew; the decision document is the same discipline pointed at the roadmap. Research is cheap. The wrong feature is not.
If you run a product, you have a version of this feature: requested constantly, obvious on its face, quietly enormous underneath. Our suggestion is not "say no." It is to spend the two days writing down what yes would cost, who tried it before you, and what the smaller honest version looks like. Then let the document argue for you.
