Dual Primary Artists

Music collaborations are the norm. Most tracks involve multiple artists, and DSPs require clear primary artist designation for catalog indexing, search, and royalty attribution. UnitedMasters previously supported only one primary artist per release, which meant collaborations couldn't be properly credited in the system.

The feature launched Android-first because that's where the largest share of the artist base lives. iOS and Web followed. Each platform had a different form architecture, so this wasn't a single design ported three times. It was the same entity model expressed through three different interaction patterns.

Artists were working around the limitation by stuffing collaborator names into the title string ("Track Name feat. Artist B" entered as the actual title). This broke DSP metadata parsing and created catalog inconsistencies that ops had to clean up manually. The workaround was so common it had become normalized behavior.

The harder problem was architectural. Adding a second primary artist isn't just a UI field. It introduces role conflicts: an artist can't be both primary and featured on the same track. Split payment calculations have to recalculate in real time as artists are added. And the collaborating artist needs to exist as a full entity in the system, not just a name string, because payments, analytics, and discoverability all depend on it.

DSP rules are hard constraints. An artist cannot be both primary and featured on the same track. Self-reference prevention: you can't add yourself as a collaborator. These aren't edge cases we could defer. They had to be handled inline at the point of entry.

The guest entity decision was the biggest architectural fork. Option one: store collaborators as metadata strings (fast to build, but no payment routing, no analytics, no discoverability). Option two: create full artist entities with a guest designation (slower to build, but enables the entire downstream system). We went with full entities. That decision shaped everything: the search flow, the validation rules, the payment recalculation, and how the feature would extend to Labels and Waterfall Releases later.

Aligned engineering, product, and ops on the entity model before touching any UI. The core question was whether guest artists should be lightweight references or full system records. The case for full entities came from mapping every downstream consumer: payments need a payee, analytics need an artist ID, DSPs need a profile URI. A metadata string satisfies none of those.

Designed role validation inline rather than at submission review. If an artist is already listed as featured, the system prevents adding them as primary before the conflict reaches ops. Visual hierarchy clarifies primary vs. featured vs. writer roles at six touchpoints across platforms: release detail, track detail, upload flow, artist search, confirmation, and the artist mapping screen.

Cross-platform search validates that the collaborating artist exists on both Spotify and Apple Music before confirming the addition. For artists not found via search, a manual entry flow lets the submitter provide DSP profile URIs directly, which handles the edge case of new or unlisted artists without blocking the release.

Cross-platform funnel conversion reached 51.8%, above the 47% initial target. Role conflicts dropped measurably, reducing ops escalations for metadata fixes after submission.

The full-entity pattern became an architectural principle beyond this feature. Labels, Split Pay, and Waterfall Releases all adopted the same model: if something needs to receive payments, appear in analytics, or surface on a DSP, it's a full entity, not a string. That was the real leverage of the decision.

Labels-specific implementation is next. Labels need different permission structures and workflow patterns for managing dual primary artists across their roster. Integration with Waterfall Releases for dual primary support in staggered release strategies.