Notes from building software.
The work behind
the software.
A closer look at our own products: the problems they address, how their workflows fit together, and the decisions that shape them.
Product stories
A mix is a file. Finishing it is a workflow.
Building MixPass meant connecting the audio people hear, the feedback they leave, and the decision to move forward. Here is how that work fits together, and where the product still needs care.
Read the story
A directory needs more than names.
MusicList connects discovery to the evidence behind a profile and the process for claiming it. Building that journey means deciding what a listing proves, who can change it, and what happens when information gets old.
Read the story
Music income does not arrive in one neat ledger.
A distributor statement, a session invoice, and a bank deposit describe different parts of the same business. Building Clef means keeping those records connected without treating an imported number as a finished decision.
Read the story
A release needs more than an upload button.
Tracks, artwork, artists, dates, and ownership details have to agree before a release can move forward. Velveteen gives us a concrete example of software that keeps incomplete work visible and treats submission as a separate decision.
Read the story
One link. Several destinations. A decision you can measure.
A listener arrives with their own preferred music service. VLVTN puts the choices on one page and records the handoff, while keeping a click-out distinct from what happens after the listener leaves.
Read the story
A label catalog should help people find their next listen.
An artist page and an album page answer different questions. Velveteen Records connects the two, keeping track lists and listening controls close to the music while giving purchases a separate path.
Read the story
The artist’s identity continues into the listening experience.
Babbage’s website carries a distinct visual identity from the first introduction to an album’s track list. Behind those pages, a catalog, player, and purchase state need to stay connected.
Read the storyThese are products we build and own. Each story identifies its current status and separates demonstrated capabilities from outcomes we have not measured.
Questions before a project
Practical guides for scoping a first version, connecting existing tools, evaluating automation, and adding AI people can check and use.
A first version people can actually use.
How to turn a broad app idea into a buildable first release, without losing the reason you wanted to make it.
Automate the part that keeps slowing you down.
A way to choose a useful first automation, whether the work happens in a spreadsheet, an inbox, or existing software.
Give AI a useful job inside the app.
Search, summaries, and assistants can improve software when they fit the work people already need to do.
How do we connect an app to the software you already use?
The interesting part starts after two systems can talk. Someone still needs to decide who owns each field, what counts as a duplicate, and what happens when the handoff stops halfway through.
How will we know an automation helps?
A draft appearing faster is easy to notice. The harder question is whether the finished job takes less effort, meets the same quality standard, and leaves fewer loose ends.
What should you bring to a software project?
You do not need a finished specification. Bring enough of the real work to explain what starts the job, where people make decisions, and what a usable result looks like.
What should an internal dashboard let people do?
A number needs a meaning, and a summary needs a next step. Start with the decision someone will make from the screen, then work back to the records and definitions that support it.
How do we make internal knowledge searchable?
Finding a plausible paragraph is only one part of answering a question. Someone needs to know whether the source is current, applies to their job, and is available to them.
What happens when an AI feature cannot answer?
A useful assistant needs an experience for the moments when its evidence, tools, or service cannot support the job. Decide that experience before the demo becomes a daily workflow.
Have something in mind?
Tell us what you want to build or improve. We’ll work out a useful first step together.