Private Music Archive

Core Problem

• Club music files are scattered across individual members
• Too shy to share publicly, but want to share internally
• Files shared on KakaoTalk are impossible to find later
• Google Drive doesn't play audio and search is inconvenient, so it ends up abandoned

Limitations of Current Methods

Proposed Solution

A private SoundCloud accessible only to club members

Core Features (Priority Order)

1. Private Streaming Playback — Listen directly on web
2. Credit/Participant Management — Manual input on upload, DB managed
3. Search — Search by lyrics, participants, or title
4. Collaboration Insights — Visualize who worked with whom on how many songs

Future Features

• AI-based automatic credit extraction (real-time lyrics sync, voice speaker separation)
• Version control (demo → mixing → mastering)

User Scenarios

Scenario 1: New Song Upload & Feedback

Club president Minsu finished a new song for the regular concert

1. Minsu uploads the audio file on web
2. Enters credits: Vocals-Jiyoung, Guitar-Minsu, Drums-Hyunwoo, Mixing-Minsu
3. Pastes lyrics, writes title and description
4. Upload complete → Club members notified
5. Members listen via streaming and leave comments
6. "Love the guitar solo!" → Minsu gets tagged notification

Scenario 2: Searching Old Songs

Freshman Eunji wants to find a song sung by a graduated senior

1. Eunji searches "2022 Regular Concert"
2. Shows list of songs uploaded during that period
3. Or searches by senior's name → Shows all songs they participated in
4. Can also search by partial lyrics
5. "Ah, this was the song!" → Stream directly

Scenario 3: Collaboration Insights

Guitarist Hyunwoo wants to see his activity record

1. Hyunwoo visits his profile page
2. Sees list of participated songs, total count (23 songs!)
3. "Worked with" visualization → 15 songs with Minsu, 12 with Jiyoung
4. Yearly activity graph → Most active in sophomore year
5. Uses this data for club activity portfolio

Architecture

Tech Stack (Expected)

• Frontend: Web-first (React/Next.js), app later
• Backend: Node.js or Python
• DB: PostgreSQL (multi-tenant)
• Storage: Initially server storage → S3 (when scaling)
• Audio Streaming: HLS or direct playback

Multi-tenant Structure

Service
├── Club A (Tenant)
│   ├── Member Management
│   ├── Music Library
│   └── Credits/Insights
├── Club B (Tenant)
│   └── ...
└── Club C (Tenant)
    └── ...

Revenue Model

Monthly subscription per club (can use school club budget)

Council Discussion Summary

Technical Perspective

Strengths:

• Not technically complex — MVP can be built quickly
• Audio streaming is well-established tech (HLS, Web Audio API)

Considerations:

• Audio file size management (5-10MB per song, potentially hundreds per club)
• Transcoding needs (various format uploads)
• Multi-tenant data isolation design critical

Business Perspective

Strengths:

• Clear target (college music clubs) — Marketing channel obvious
• Can pay with club budget — Easier B2B-like decision making
• Network effect — One club uses it, others learn about it

Considerations:

• Pricing: What's appropriate? (₩5,000/month? ₩10,000/month?)
• Seasonality: Usage difference between semester and vacation
• Alumni handling: What happens to data/accounts after graduation?

UX Perspective

Strengths:

• Clear SoundCloud reference — Low user learning cost
• Simple core flow: Upload → Play → Search

Considerations:

• Credit input UX is key — Won't use if tedious
• Autocomplete essential (select from existing members)
• Role tags preset (vocals, guitar, mixing, etc.)
• Mobile web optimization essential — Likely to listen on phone

Risks & Mitigations

Next Steps

1. Define MVP features (streaming + credits + basic search)
2. Wireframe/prototype
3. Interview/validate with 1-2 clubs
4. Finalize tech stack and start development
5. Beta test (with real club)