TheFlow is a social music platform. I was its sole product designer for 21 months, taking the iOS app from concept to invite-only beta. This case study focuses on the publishing system I defined for artists to upload, release, and manage music.

When I joined, TheFlow was still a concept, with no product documentation or engineering team. The business needed artists to bring their music to the platform. Without a catalog, listeners had nothing to discover or support. Artists handled their uploads and releases in the app.

Role: Product Designer Engagement: 21 months Platform: iOS Responsibilities: Product Architecture, Project Strategy, Interaction Design, User research, Documentation Team: 1 Founder, 1 Designer, 5 Engineers, 2 QA

The first upload flow I designed was simple: create an album, add tracks, choose a release date, and submit. When I reviewed it with musicians, they raised cases the flow did not handle. A track could have multiple primary artists. Some songs needed to go live before the rest of the album. Copyright or AI checks could fail. Editing rules changed depending on whether a release was a draft, scheduled, flagged, or live. I needed one publishing model that could handle these cases without making the upload flow harder to use.

TheFlow combined the listener and artist experience in one app. Artists could discover music and manage their own releases in the same place. Before development, I built a prototype and reviewed it with eight musicians. I wanted to confirm they understood the concept and main flows. They responded positively to the concept and understood the business model. After those sessions, the founder funded development and hired engineers.

After an album was submitted, each track went through verification. If every track passed, the album went live or waited for its release date. If any track failed, I paused the album until the issue was fixed. The artist could replace the audio and resubmit, delete the track, or start a dispute. The founder and I defined the dispute rules, including what happened while a dispute was under review and after it was resolved or rejected.

Pausing the album avoided a harder recovery problem. Once an album was live, it could not be edited, only deleted. If it went live without a flagged track, restoring that track later would mean deleting and re-uploading the whole album.

The first credits model worked when there was only one primary artist. Musicians asked what should happen when two or more primary artists shared a track equally and another collaborator, such as a producer, needed a percentage. They also said recalculating by hand was a pain. TheFlow always kept 20%, with the remaining 80% going to artists and collaborators. I considered making a separate upload flow for bands, but the rest of the release process was the same, so a second flow would give the product team more to build and artists another version of the process to learn. Instead, I added two ways to calculate credits inside the existing flow: Individual Stake and Group Stake. Individual Stake takes the collaborator's percentage from one primary artist, while Group Stake spreads it across the primary artists.

Musicians told me that prereleasing songs before the full album mattered to them, and my research showed the same pattern in existing music releases. Each album had one release date. One option was to treat every early song as a separate single, but that would separate the song from the album it belonged to. I added a prerelease date at the track level, with one rule: the album date had to come after the latest prereleased track. This let artists release songs early while keeping them inside the same album.

Apple approved TheFlow for the App Store, and the product reached invite-only beta. Engineering and QA used my release specifications and component system during implementation. My engagement ended in April 2026, and the team continued development using the Figma files, design system, and product documentation I created.

At first, I defined release rules while designing individual screens. As the product grew, this caused redesigns, conflicting permissions, and questions from engineering. If I were starting a similar product now, I would map the states, transitions, permissions, and recovery paths earlier. I would use that model before going deep into individual screens.