<aside> ⚠️

TL;DR: Most music data disasters follow predictable patterns. Knowing what not to do is often more valuable than knowing what to do. Here are the mistakes that haunt artists, managers, and labels at scale.

</aside>

flowchart LR
    subgraph Bad["🚨 Anti-Patterns"]
        direction TB
        B1["One Giant Spreadsheet"]
        B2["Comma-Separated Lists"]
        B3["Copy-Paste Syndrome"]
        B4["Fix It Later Debt"]
    end
    
    subgraph Good["✅ Best Practices"]
        direction TB
        G1["Separate Related Tables"]
        G2["Individual Records"]
        G3["Reference; Don't Copy"]
        G4["Document at Creation"]
    end
    
    B1 --> |"fix"| G1
    B2 --> |"fix"| G2
    B3 --> |"fix"| G3
    B4 --> |"fix"| G4
    
    classDef bad fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
    classDef good fill:#d1fae5,stroke:#059669,color:#064e3b
    
    class B1,B2,B3,B4 bad
    class G1,G2,G3,G4 good

The "One Giant Spreadsheet" trap

<aside> 🚨

The pattern: Everything in one spreadsheet — songs, albums, contacts, royalties, to-dos, ideas, all in different tabs (or worse, the same tab).

Why it happens: It's easy to start. No setup required. Just add columns as you need them.

Why it fails:

• Can't link data across tabs meaningfully
• Duplicate information everywhere
• No way to ask cross-cutting questions ("all songs by this writer")
• Breaks down completely past ~100 songs

The fix: Separate concerns into distinct, related tables. Songs, Albums, Contacts, Writers — each in their own space, linked by relations.

</aside>

The "Comma-Separated List" problem

<aside> 🚨

The pattern: Storing multiple values in a single text field.

Writers: "Jordan Smith, Alex Jones, Sam Lee"

Why it happens: Feels simpler than setting up relations.

Why it fails:

• Can't filter by individual writer
• Can't calculate splits
• Spelling variations create phantom duplicates
• "Jordan Smith" ≠ "Jordan smith" ≠ "J. Smith"

The fix: Each writer gets their own record. Link songs to writer records via relations. Now you can filter, aggregate, and maintain consistency.

</aside>

The "Copy-Paste" syndrome

<aside> 🚨

The pattern: Copying data from one place to another instead of referencing it.

Why it happens: Feels faster in the moment.

Why it fails:

• Source changes, copies don't update
• Multiple "truths" for the same data
• Hours spent hunting down discrepancies

The fix: Reference, don't copy. If you need contact info on a song, relate to the contact record. If you need album release date on a track, pull it via rollup.

</aside>

The "I'll fix it later" debt

<aside> 🚨

The pattern: Releasing music without proper metadata, planning to "clean it up later."

Why it happens: Shipping feels more important than documenting.

Why it fails:

• "Later" never comes
• Debt compounds with every release
• Eventually, cleanup becomes a multi-week project
• Some info (who played on that session 3 years ago?) is lost forever

The fix: Build documentation into your release workflow. No release ships without metadata complete. Make it a checklist, not an afterthought.

</aside>

The "Too Many Tools" fragmentation

<aside> 🚨

The pattern: Contacts in one app, songs in a spreadsheet, tasks in another app, notes in a third.

Why it happens: Each tool does one thing well. You accumulate them over time.

Why it fails:

• No connections between data
• Context-switching overhead
• Impossible to see the full picture
• "Which app has that info?" becomes a daily question

The fix: Consolidate where possible. A unified system with relations beats five disconnected best-in-class tools.

</aside>

The "Premature Complexity" trap