The Side Project That Refused to Stay Small
Our Fun page exists for the projects we build because the itch is there: instruments, experiments, toys. Stem Shovel started as exactly that. The first commit, on September 11, is titled "multi-stem player proof of concept," and the plan was a weekend of Web Audio: load a song's stems in the browser, play them in sync, mute and solo, nothing more.
Forty days later it is a product. About 140 released versions, 29 architecture documents, a billing system with plans and storage limits, accounts with passkeys, an inbox with email digests, AI-drafted chord charts, and a tools menu holding a tuner, a metronome, a piano, and a drum machine that are free for anyone. This post is about what happened in between, because the in-between is the part we keep learning from.
The itch does not know where it is going
The proof of concept worked the first evening, which is the dangerous part. A synced stem player immediately wants a fader per stem. Faders want a waveform to seek on. A waveform wants a section timeline. Sections want a chart, and a chart sitting next to the music wants lyrics and notes and comments pinned to moments in the song. At each step the addition was small, obvious, and demanded by the step before it. There was never a day the project decided to become a product; there was a sequence of forty days in which stopping always felt more arbitrary than continuing.
We have built long enough to know this pattern cuts both ways. Most side projects should stay small, and most of ours do. The signal that this one was different was not enthusiasm, which every project has in week one. It was that the roadmap kept being written by use: one of us would bring a real song, hit a real wall, and the wall became the next version.
Velocity has a shape now
About 140 versions in forty days is not a pace one person types. It is the pace of one person directing a bench of coding agents, and Stem Shovel is the most complete expression yet of how we build that way. The repository is organized as much for agent legibility as for human reading: a working agreement describing the rules of the house, a per-file guard that answers "which rules and boundaries apply here" before an edit, a screenshot bot that signs in and captures any page so an agent can see its own work, smoke scripts that walk every route, and more than two thousand tests that gate it all.
The striking economics are not the speed of writing code. It is that the discipline which used to be overhead now pays twice. Every architecture document, every tested invariant, every house rule in the linter is context an agent can use, which means the structure of the codebase sets the cost of every future change. We said this in the abstract when we logged the research on refactoring economics; Stem Shovel is what it looks like applied for forty consecutive days.
Restraint is a feature
Ambition grew, but so did the discipline of saying no in writing. When the obvious next idea arrived, storing and syncing the DAW session files behind the stems, we did the research before the feature: priced the storage, studied the two funded companies that attempted sync at scale and gave up, and wrote the conclusion into the repository as a decision document marked research only, nothing built. The product got the smaller, honest version of the idea instead. The same reflex, documented refusal, is all over the project, and it is the only reason a forty-day-old codebase is not a swamp.
The other restraint was keeping the free things free. The tuner, metronome, piano, and drum machine are public pages with no account, because the Fun series is where this came from and a musician with thirty seconds and a guitar should not meet a sign-up form. They also happen to be the best front door the product has, which is a lesson our agent-readiness work keeps teaching in another costume: reachable, genuinely useful substance beats every growth trick.
What carried over from the day job
Stem Shovel borrowed the practices this studio runs on, and they transferred cleanly to a product none of our clients asked for. A findings file records every browser trap with the precision of a lab notebook, because hard-won platform knowledge is an asset (that file is worth a post of its own). The changelog is honest about mistakes. Decisions get documents. And the whole surface, like this site, is built to be read by agents as comfortably as by people.
Whether Stem Shovel the product succeeds is a question the next few hundred versions will answer, and we hold that loosely. Stem Shovel the demonstration has already paid for itself: it is what a one-person team with good discipline and a bench of agents can ship in forty days, measured not in demos but in versions, tests, and paying infrastructure. The itch was real. It usually is. The difference is what you scratch it with.
