Turning a founder's idea into an iOS platform for artists and listeners, from onboarding and uploads to payouts, subscriptions, and moderation.

TheFlow is an iOS music and social platform focused on creator ownership and payouts that depend on listening time.

I joined when the project was just an idea. Over 21 months, I worked with the founder to figure out how it would work, designed the main user journeys, wrote product specs, built the design system, and supported development. By the time I left, the product had reached invite-only beta and passed Apple’s App Store review.

Role: Sole Product Designer (Founding-stage) Timeline: July 2024 to April 2026 Platform: iOS Responsibilities: Product Architecture, Information Architecture, Interaction Design, Visual Design, Design System, Prototyping, Concept Validation, Specifications & Documentation, Design-to-Development Handoff Team: 1 Founder, 1 Designer, 5 Engineers, 2 QA

When I started in July 2024, TheFlow was only an idea. There was no product documentation, no design system, and no clear requirements. All we had were some rough wireframes, a logo, and a strong vision from the founder.

The idea was unusual. Artists would be paid based on listening time rather than stream counts. Fans could subscribe directly to artists. The platform would run as a creator-owned cooperative.

Designing the screens was not the hard part. The real challenge was turning the idea into a working product. I worked with the founder to shape the structure, define the flows, and set the rules. Before development began, I created early concepts for the main features. We shared these with musicians for feedback, and their positive response helped us move forward and bring in a development team.

The scope grew as the product did. I ended up owning the full experience while building the design system and documentation that the team needed to ship.

I designed the product for both listeners and artists. Since every artist starts as a listener, the product needed to support both listening and creating in one shared system.

In addition to the main flows, I defined edge cases, state behavior, and product rules for the team. The work covered three main areas.

Transparency sits at the center of TheFlow's payout model. At the end of each month, a Paid Attention screen shows listeners where their money went, down to TheFlow's fee and each artist's share. The credits set on a track decide how its payout is divided. That made the credits system more than metadata. It directly controlled payouts.

The first version worked for solo artists. TheFlow takes 20%, the primary artist gets the remaining 80%, and if there are collaborators, their share comes from the primary artist’s portion. The payout model stayed simple and easy to follow.

Then a musician review surfaced a question the solo model couldn’t answer. "How does this work for a band? If four artists share a track equally, where does a producer’s percentage come from?"

One option was to create a separate upload flow for bands. This would have made the payout logic simpler, but it would also have required maintaining a second system. Instead, I kept a single upload flow and expanded the credits system.

The solution was a toggle between Individual Stake and Group Stake. Individual Stake kept the solo flow intact, with the collaborator’s share coming from a single primary artist. Group Stake handled bands, spreading collaborator percentages across all primary artists based on their shares. Every share is a cut of the artist portion, the 80% left after TheFlow’s fee, so the splits always add up to 80. If two artists held 40% each and a producer took 10%, both dropped to 35%.

This approach kept the upload flow simple and made the payout model flexible enough for bands.

TheFlow allows staggered releases, so artists can release tracks before the full album is out. This changes the idea of an album from a single release event to a container for tracks in different release states. Some tracks might already be live, some scheduled, and others still locked.

The simple solution would have been to hide the album until everything was ready, but we chose not to. As soon as an album had at least one live track, it became visible to fans, even if the rest of the tracks were still scheduled or locked. Fans could see upcoming tracks, browse the full tracklist, and play whatever was already available. Albums with no live tracks stayed private to the artist in the Unpublished screen.

This made the album part of the release strategy. Artists could build anticipation and encourage subscriptions before the full release. It also created a new challenge, since a single album could now include public, subscriber-only, purchase-only, and unreleased tracks.

The main question became what could change after publishing. That’s where we set limits. Artists could still edit pricing, lyrics, credits, and genres. Some settings became permanent. Purchase-only could be turned off but not turned back on, and subscriber-only was only available if set before publishing.

We were careful with flexibility. Artists could adjust their release strategy, but the parts listeners depended on stayed consistent.

The original design system was made for a standard developer handoff. This changed when the team started using Claude Code and generating screens directly from Figma.

The system still worked for developers, but not for AI. A single visual value could mean different things depending on context. Developers could figure this out, but the AI could not, resulting in inconsistent results, hardcoded values, and UI drift.

Rebuilding the whole system was not realistic, so I focused on the parts that were blocking the build. I restructured it into three token layers: primitive, semantic, and component, and added a Style Mapping layer between them. This allowed the same visual value to have different meanings depending on where it was used. I started with the core components, where ambiguity was causing the biggest problems.

The migration took five days. It unblocked the build and stabilized the generated UI. It also changed how I think about design systems. Now, they have to be machine-readable, not only by the team.

The founder and I reviewed the work two or three times a week, which helped shape the scope, behavior, and priorities. We also met with musicians weekly to review designs. Some of the most important product questions came from those sessions, including the band payout problem. After we adjusted the credits model before the invite-only stage, the payout structure made sense to the musicians.

Later, once artists had access, they left notes in a shared document whenever something in the app was unclear or did not work. After the main flows were stable, we ran an invite-only TestFlight beta with about 50 musicians and invited users. Most artists finished onboarding and uploaded their music with little trouble.

Over 21 months, TheFlow went from an idea to a fully designed iOS product:

15+ product areas

40+ user flows

200+ unique screens

70+ reusable components

15 product specs

The product passed Apple’s review and reached invite-only beta.

During beta, we tracked the issues that came up, and most were implementation bugs rather than product flaws. The product rules, states, and flows held up well. My documentation also helped QA, who used it to check behavior, edge cases, and state transitions during the build.

My active phase ended in April 2026. The product is now being developed using the designs and system I delivered.

1. I was defining the product, not just designing it. TheFlow was the first project where I did product management as well as design. I wrote the specs, set the rules for revenue, access, and release states, and shaped the product structure with the founder. Design and product decisions were closely linked: changing how splits worked meant changing the credits UI, and changing the UI meant changing the model. This is now how I expect to work on early-stage products.

2. The right people in the room beat internal debate. The band payout problem came up because real musicians reviewed the designs every week. One of them asked a question we had not thought of, and it exposed a flaw in a model we thought was finished. I would rather keep the actual users close enough to find these gaps than rely only on internal review.