Music Label OS

My Contributions

• —Defined product strategy and catalog-first system architecture
• —Designed end-to-end workflows for tracks, artists, and projects
• —Shaped pre-release decision-support features around analysis and collaboration
• —Built and shipped the MVP under real-world constraints
• —Worked directly with musicians to validate assumptions and refine workflows

Challenge

Independent artists and small label teams often need to make important creative and operational decisions before traditional streaming data is useful. They are deciding which tracks to prioritize, how to organize releases, how to align collaborators, and how to keep creative direction, metadata, and assets connected across a project. In practice, those decisions are often spread across notes, folders, spreadsheets, and messaging threads.

Most music tools become more valuable after distribution. I wanted to explore a different starting point: a system that could help teams make better decisions earlier, while the work was still taking shape.

Constraints

This was a 0→1 product effort built under real-world limits. I was shaping the product strategy, user experience, and system structure while also helping bring the MVP to life. The product also sat in a difficult space: independent music teams often have real workflow complexity, but they do not always have the time, team size, or budget to adopt heavy operational software.

There were also product constraints specific to the domain:

• early-stage music projects often lack reliable downstream performance signals
• workflows vary widely across solo artists, collaborators, and small labels
• AI needed to be useful without becoming vague, overbearing, or untrustworthy
• the product needed a clear data foundation before higher-level insights would be credible

Approach

I began by treating catalog structure as the foundation rather than an afterthought. Instead of building around dashboard-style performance views, I prioritized a catalog-first model that organized tracks, artists, and projects in a way that could support both everyday workflow and future intelligence.

That led to several key product decisions.

1. Structure before analytics

I chose to build around clean relationships between tracks, artists, and projects before leaning heavily into performance or reporting features. This created a stronger foundation for collaboration, metadata quality, and later analysis, even though it meant the product would feel less like a conventional “music analytics” tool in its earliest form.

2. Pre-release decision support over post-release reporting

Rather than centering the product around streaming metrics, I focused the experience on decisions that happen before release: organizing work, evaluating tracks, capturing context, and helping users compare options while a project is still moving. This better matched the real workflow gaps I had seen while working with independent musicians.

3. AI as scoped assistance, not automated judgment

I wanted AI to help users move faster without pretending to replace creative judgment. The product was designed so insights stayed attached to real entities like tracks and projects, and recommendations were framed as support for decision-making rather than final answers. That balance mattered because trust was more important than novelty.

4. Product direction informed by lived domain context

Before building Music Label OS, I had already worked directly with musicians in roles spanning collaboration, engineering, and performance. That experience shaped early assumptions about how projects actually move, where communication breaks down, and why generic productivity tooling often fails in music contexts. I used that domain familiarity to shape the system language, early workflows, and the overall product direction.

Outcome

Music Label OS evolved from an earlier paid Notion-based workflow into a standalone multi-tenant SaaS MVP designed around structured catalog management, collaboration, and analysis-assisted decision support.

The early signals were meaningful:

• the original Notion version generated paid purchases from external users
• the MVP launched with a fully external paying pilot customer
• additional free users began using the product in active weekly workflows
• the product validated demand for pre-release decision support in music operations

More importantly, the project clarified a strong product direction: independent music teams do not just need another analytics view. They need better structure, better context, and better decision support while the work is still being created.

What I’d improve next

The next improvements would focus on clarity, progression, and collaboration.

First, I would make onboarding more opinionated so users can more quickly understand how the system fits their workflow. The product asks users to adopt structure early, so the payoff needs to become visible faster.

Second, I would strengthen project-level and album-level experiences. The product already supports track-level thinking well, but creative teams often make decisions at the project level, where sequencing, cohesion, readiness, and thematic alignment matter more than any single track.

Third, I would continue refining how insights are presented. The long-term goal is not just to generate analysis, but to help users act on it in context: discussing it, comparing options, and making stronger decisions together without losing creative control.