# GarageBand.com Rebuild ## Product Requirements and System Specification **Document status:** Initial product specification **Reference product:** GarageBand.com, primarily circa 2003–2005 **Purpose:** Provide sufficient product, behavioural and technical detail for a software team to build a working modern recreation of the GarageBand.com independent-music review community. --- # 1. Executive Summary GarageBand.com was not primarily a music-hosting website. Its defining product was a **marketplace for human attention**. Musicians wanted three scarce things: 1. people to actually listen to their music; 2. credible feedback from listeners and other musicians; 3. a fair mechanism through which good music could gain exposure without an existing audience. GarageBand.com solved those problems by making attention reciprocal. An artist could not simply upload unlimited music and expect an audience. To submit a song into the site's evaluation system, musicians first had to listen to and review music submitted by other musicians. By 2004–05, GarageBand.com required musicians to review approximately **30 songs before uploading a song**. CEO Ali Partovi described this requirement as the mechanism that generated thousands of daily reviews and allowed the platform to process music submitted by approximately 125,000 member bands. This created a self-sustaining loop: ```text Artist wants feedback ↓ Artist reviews other musicians ↓ Those musicians receive feedback ↓ Artist earns ability to submit ↓ Artist's track enters review system ↓ Other musicians review it ↓ Track receives feedback + ranking ↓ Artist improves / submits again ``` This loop is the product. Everything else, including artist profiles, charts, awards, radio, discovery, downloads and community features, should be understood as infrastructure surrounding this mechanism. The objective of this project is therefore **not to build another SoundCloud**. It is to rebuild a structured reciprocal evaluation network in which: > **Every submitted song receives genuine human listening because every participant contributes human listening.** --- # 2. Historical Product Thesis GarageBand.com explicitly described its review system as the core of the company. In January 2005, CEO Ali Partovi explained that every musician submitting a song first had to review 30 songs from other musicians. He described the resulting written feedback and merit-based rankings as: > “the core of what GarageBand.com is about.” The system solved several problems simultaneously. ### 2.1 Guaranteed attention Every valid submission entered a controlled review queue. Unlike conventional social media: * artists did not require followers; * artists did not have to buy advertising; * artists did not need algorithmic virality; * friends could not simply coordinate votes; * established popularity was not supposed to determine initial exposure. An official GarageBand.com help document explained that every uploaded track receP1+r436F=323536\P1+r6B75=1B4F41\P1+r6B64=1B4F42\P1+r6B72=1B4F43\P1+r6B6C=1B4F44\P1+r2332=1B5B313B3248\P1+r2334=1B5B313B3244\P1+r2569=1B5B313B3243\P1+r2A37=1B5B313B3246\P1+r6B31=1B4F50\ived a predetermined number of reviews. Requiring musicians to review other tracks ensured that enough review capacity existed to process every submission. ### 2.2 Reciprocal contribution Users seeking attention were required to supply attention. The system therefore prevented the classic creator-platform imbalance: ```text 100,000 creators want listeners but almost nobody wants to listen ``` GarageBand.com converted creators into listeners. ### 2.3 Blind evaluation Tracks presented for evaluation were assigned rather than deliberately selected by reviewers. Contemporary descriptions state that songs were anonymously and randomly presented, specifically to discourage fans, friends and artists from manipulating results. ### 2.4 Structured comparisoP1$r2 q\[?12;2$yn The 2004 system was described by Creative Commons as allowing listeners to evaluate one song against another. Period descriptions of the review experience indicate the following basic pattern: ```text Song A ↓ listen ↓ rate/review Song B ↓ listen ↓ rate/review Which song did you prefer? ``` This pairwise comparison appears to have contributed to the site's ranking calculations. ### 2.5 Reviewer accountability Reviewers themselves had reputations. GarageBand.com's FAQ described a **Reviewer Rating** derived from feedback supplied by artists receiving reviews. Artists were asked questions including whether: * the reviewer had genuinely listened to the track; * the review contained meaningful praise; * the criticism was constructive. The reviewer's displayed score was calculated from previous artists' assessments of their reviews. This creates an important second feedback loop: ```text Artist evaluates song ↓ Artist writes review ↓ Reviewed artist evaluates reviewer ↓ Reviewer develops reputation ↓ Higher-quality reviewing is incentivised ``` That mechanism should be regarded as a fundamental part of the product rather than an optional community feature. --- # 3. Product Vision Build a music platform where **unknown music can receive meaningful human evaluation independent of an artist's existing popularity**. The platform should answer four questions for every submitted song: 1. **Did people actually listen?** 2. **What did they think?** 3. **Why did they think it?** 4. **How does this track perform against comparable music?** The corresponding promise to an artist is: > Submit your music here and real people will listen to it. The corresponding obligation is: > To receive attention, you must contribute attention. --- # 4. Product Principles ## 4.1 Attention must be earned, not purchased by popularity Follower count must not determine whether submitted music gets reviewed. ## 4.2 Every valid submission receives reviews Submission volume and review capacity must remain mathematically balanced. ## 4.3 Evaluation occurs before identity matters Artist popularity, appearance, social following and promotional assets should not influence the primary evaluation. ## 4.4 Reviewers cannot choose individual tracks Reviewers may choose broad categories such as genre, but the platform chooses the specific track. ## 4.5 Review quality matters A one-line dismissive review and a thoughtful production critique must not be economically equivalent. ## 4.6 Rankings represent evidence Charts should emerge from structured evaluation, not likes, follower counts or paid promotion. ## 4.7 Constructive negative feedback is legitimate The platform should not optimise exclusively for positivity. ## 4.8 Discovery follows evaluation The system should first evaluate music under controlled conditions and subsequently expose successful music to broader audiences. --- # 5. User Types The historical product blurred several roles because most users were musicians. The rebuilt product should model them explicitly. ## 5.1 Listener Can: * discover music; * listen to public tracks; * follow artists; * create playlists; * rate public tracks where appropriate; * become a reviewer. ## 5.2 Reviewer Can: * enter review sessions; * receive randomly assigned tracks; * submit structured ratings; * submit written feedback; * build reviewer reputation; * earn review credits. ## 5.3 Artist Can: * create artist profiles; * upload tracks; * submit tracks into review; * receive reviews; * evaluate reviewer quality; * view analytics; * appear in charts; * receive awards. An Artist account may also act as a Reviewer. ## 5.4 Curator Future role. Can identify high-performing reviewed tracks for: * playlists; * editorial coverage; * sync opportunities; * radio; * label scouting; * showcases. ## 5.5 Moderator Can: * review reports; * invalidate fraudulent reviews; * remove prohibited content; * resolve plagiarism/copyright disputes; * suspend accounts; * invalidate ranking activity. ## 5.6 Administrator Can manage: * genres; * review rules; * ranking parameters; * credits; * awards; * featured placements; * moderation thresholds; * fraud controls. --- # 6. Core Economic Unit: Review Credits The platform needs an internal representation of contributed attention. Call this a **Review Credit**. Historically, approximately 30 reviewed songs were required for a free upload by 2004–05. The modern system should generalise that concept. Example: ```text 1 completed qualified review = 1 review credit ``` Submitting one song might require: ```text 20 review credits ``` The precise value should be configurable rather than hard-coded. --- # 7. Credit Accounting Credits should be recorded through an immutable ledger. ```text review_credit_transactions id user_id type amount reason related_review_id related_submission_id created_at ``` Example transactions: ```text +1 completed qualified review +0.5 bonus for highly-rated review -20 submitted track +5 promotional reward -1 review invalidated by moderation ``` Never store only: ```text users.credit_balance ``` The balance should be derivable from ledger transactions. A cached balance may additionally exist for performance. --- # 8. Review Quality Multiplier A modern implementation should improve upon the historical binary economics. Instead of every review generating identical credit, reviewer reputation can affect credit generation. Example: ```text low-quality review = 0 credits valid review = 1 credit excellent review = 1.25 credits ``` The goal is not to create elite reviewers. The goal is to make: ```text "nice song" ``` less economically valuable than: ```text "The vocal sits well against the verses, but the kick and bass are masking each other below approximately 100 Hz. The chorus also feels less dynamic than the pre-chorus." ``` --- # 9. Primary Product Loop ```text REGISTER ↓ SELECT INTERESTS / GENRES ↓ CREATE ARTIST PROFILE ↓ REVIEW MUSIC ↓ EARN CREDITS ↓ UPLOAD TRACK ↓ SUBMIT FOR REVIEW ↓ TRACK ENTERS REVIEW QUEUE ↓ REVIEWERS RECEIVE TRACK ↓ REVIEWS + RATINGS COLLECTED ↓ RESULT CALCULATED ↓ ARTIST RECEIVES FEEDBACK ↓ ARTIST RATES REVIEW QUALITY ↓ TRACK ENTERS CHARTS / AWARDS ↓ ARTIST REVISES / RELEASES / SUBMITS AGAIN ``` This must remain the dominant user journey. --- # 10. Artist Onboarding Minimum onboarding information: ```text email username country primary genres listener genres musician status instruments / production disciplines ``` Optional: ```text city biography website social links DAW production role influences ``` The system should immediately communicate: ```text You currently have: 0 review credits You need: 20 credits to submit a track ``` Primary CTA: **Review Music** Not: **Upload** This is a deliberate product decision. --- # 11. Artist Profiles Historical GarageBand.com artist pages acted as public music profiles and exposed reviews, awards and chart performance. A modern profile should contain: ```text artist name avatar / artwork location genres biography external links tracks followers awards chart history review statistics ``` Each track card should expose: ```text artwork track title duration genre play button average rating review count current chart position highest chart position awards ``` Public written reviews should be configurable by the artist. --- # 12. Upload Flow Uploading and submitting should be separate concepts. An artist may upload a track privately without immediately entering review. ## Screen 1: Upload Required: ```text audio file track title primary genre ``` Optional: ```text secondary genre release status lyrics ISRC artwork credits description ``` ## Screen 2: Rights declaration Artist confirms: ```text I own or control sufficient rights to upload this recording. ``` Potential licence choices: ```text All rights reserved Public streaming permitted Download permitted Creative Commons licence ``` GarageBand.com added optional Creative Commons licensing during 2004. ## Screen 3: Review submission Display: ```text Review credits available: 28 Submission cost: 20 Reviews expected: 20+ ``` CTA: **Submit for Review** --- # 13. Submission State Machine ```text DRAFT ↓ UPLOADED ↓ READY_FOR_SUBMISSION ↓ SUBMITTED ↓ QUEUED ↓ UNDER_REVIEW ↓ MINIMUM_REVIEWS_REACHED ↓ SCORING ↓ RANKED ↓ ARCHIVED ``` Possible exceptional states: ```text PAUSED REJECTED COPYRIGHT_HOLD MODERATION_HOLD WITHDRAWN INVALIDATED ``` --- # 14. Review Queue This is the core infrastructure service. A reviewer does not query tracks directly. They request: ```text GET /review/next ``` The queue service determines which track they receive. --- # 15. Review Matching Rules The system should prevent: ### Self review ```text reviewer.artist_id != submission.artist_id ``` ### Repeated reviewing Do not assign the same submission twice to the same reviewer. ### Social conflicts Where detectable, reduce assignment probability for: ```text mutually-following users known collaborators same organisation shared IP patterns previous reciprocal reviewing relationships ``` ### Genre mismatch A reviewer may select: ```text Electronic Rock Hip-hop Jazz Any genre ``` Tracks should normally remain within appropriate genre pools. Historical descriptions explicitly noted that GarageBand.com avoided directly comparing music from incompatible genres. --- # 16. Anonymous Review Mode During primary evaluation, hide: ```text artist name artist image location followers streaming statistics awards social links existing rating existing reviews chart position ``` Show only: ```text audio player track title: optional genre duration review controls ``` For maximum bias protection, the track title may also be hidden until after submission. --- # 17. Listening Requirement A review should not qualify immediately after playback starts. A modern implementation can measure: ```text seconds_played percentage_played scrubbing behaviour pause behaviour window visibility playback speed ``` Example eligibility: ```text review qualification = max( 90 seconds listened, 50% of track listened ) ``` Exact thresholds should be tested experimentally. The product should not require users to listen to a seven-minute song in full merely to submit useful feedback. --- # 18. Review Screen Primary layout: ```text ------------------------------------------------ REVIEW 4 OF 20 +12 credits ------------------------------------------------ [ waveform / player ] 03:42 [ play ] ------------------------------------------------ How would you rate this track overall? ☆ ☆ ☆ ☆ ☆ ------------------------------------------------ Production ☆ ☆ ☆ ☆ ☆ Songwriting ☆ ☆ ☆ ☆ ☆ Performance ☆ ☆ ☆ ☆ ☆ Originality ☆ ☆ ☆ ☆ ☆ ------------------------------------------------ What worked? [ textarea ] What could be improved? [ textarea ] ------------------------------------------------ [ SUBMIT REVIEW ] ------------------------------------------------ ``` Genre-specific attributes may replace generic ones. Electronic: ```text production sound design arrangement mix originality ``` Singer-songwriter: ```text songwriting lyrics performance arrangement production ``` --- # 19. Historical Review Categories GarageBand.com's awards demonstrate that reviewers evaluated numerous musical attributes. Documented historical award categories included combinations of: ```text Best Male Vocals Best Female Vocals Best Guitars Best Drums Best Bass Best Keyboards Best Programming Best Production Best Lyrics Best Melody Best Beat Best Mood Most Original Grooviest Rhythm Rocking Track Feel Good Track Chill-Out Track Best Dance Track ``` Examples from 2004–05 artist records show these categories being awarded based on reviewer feedback. These categories are useful because they convert review data into positive recognitions beyond a single numerical chart position. --- # 20. Pairwise Comparison After reviewing Track A and Track B: ```text Which track would you rather hear again? ○ Track A ○ Track B ○ No preference ``` Alternative phrasing: ```text Which track do you prefer overall? ``` This pairwise signal should be stored separately from star ratings. ```text pairwise_comparisons id reviewer_id submission_a_id submission_b_id preferred_submission_id created_at ``` Pairwise comparison is particularly valuable because star ratings suffer from reviewer calibration problems. One reviewer may consider: ```text 3 / 5 = good ``` while another considers: ```text 3 / 5 = mediocre ``` Pairwise preference asks a simpler question: > Which of these two is better? --- # 21. Review Completion When a review is submitted: 1. validate minimum listening threshold; 2. validate required ratings; 3. validate minimum feedback requirements; 4. run spam/abuse checks; 5. store review; 6. credit reviewer; 7. update submission review count; 8. update scoring models; 9. test submission completion threshold; 10. return next assigned track. The review workflow must feel continuous. Avoid repeatedly returning users to a dashboard. Ideal flow: ```text Submit Review ↓ +1 credit animation ↓ next track automatically loaded ``` --- # 22. Reviewer Reputation Every reviewer should have a reputation profile. Example: ```text Reviewer score: 87 / 100 Reviews written: 428 Artists finding reviews useful: 91% Reviews invalidated: 1.2% Typical listening completion: 78% ``` --- # 23. Artist Evaluation of Reviews After an artist receives feedback: ```text Was this review useful? Yes / Somewhat / No ``` Optionally expand: ```text Did the reviewer appear to have listened carefully? Yes / No Was the feedback specific? Yes / No Was criticism constructive? Yes / No ``` This closely follows GarageBand.com's historical Reviewer Rating concept. The review author must **not** see which artist gave which reviewer-quality rating. --- # 24. Reviewer Reputation Formula Example implementation: ```text R = 0.30 usefulness + 0.20 listening_quality + 0.20 specificity + 0.15 moderation_history + 0.10 review_completion_quality + 0.05 reviewer_consistency ``` Normalise to: ```text 0–100 ``` Apply Bayesian shrinkage for new reviewers so a reviewer cannot obtain a 100 score from one evaluation. --- # 25. Review Weighting Do not blindly weight every rating equally. Example: ```text effective_rating = raw_rating × reviewer_weight ``` Reviewer weight might range from: ```text 0.7 – 1.2 ``` Avoid excessively powerful reviewer weighting. The system must not evolve into a small critic elite controlling rankings. --- # 26. Anti-Retaliation Design A major risk is: ```text Reviewer leaves negative review ↓ Artist gives reviewer poor reputation ``` Mitigations: * reviewer-quality assessments remain anonymous; * extreme artist rating behaviour is down-weighted; * ratings are aggregated over many artists; * textual negativity is not interpreted as low review quality; * specificity and listening behaviour supply independent signals. A negative but insightful review should increase reviewer reputation. --- # 27. Submission Review Target Every submission needs a target number of qualified reviews. Example: ```text minimum_reviews = 20 target_reviews = 30 maximum_reviews = 40 ``` The queue prioritises tracks with insufficient review coverage. Historical GarageBand.com deliberately sought a controlled review count for every submitted track rather than allowing popular tracks to absorb all available attention. This is crucial. --- # 28. Queue Priority Algorithm Conceptually: ```text priority = review_deficit × age_factor × genre_capacity_factor × confidence_requirement ``` Where: ```text review_deficit = target_reviews - qualified_reviews ``` Tracks approaching statistical uncertainty can receive additional reviews. --- # 29. Cold-Start Protection New submissions must receive priority independent of artist popularity. No public song should permanently remain: ```text 0 reviews ``` unless it failed moderation or the review economy itself lacks sufficient participants. --- # 30. Ranking Philosophy The original site was designed as a merit-based discovery system. Contemporary descriptions emphasised: * randomly allocated review assignments; * anti-ballot-stuffing design; * proprietary statistical ranking; * charts recalculated as votes arrived. The new platform should preserve this philosophy without claiming to recreate GarageBand.com's proprietary algorithm. --- # 31. Ranking Inputs Recommended inputs: ```text pairwise win rate overall rating attribute ratings reviewer reliability sample size rating variance review recency confidence interval ``` Do **not** include: ```text followers page views social shares artist popularity paid plan advertising spend ``` within the core merit score. --- # 32. Recommended Ranking Model A robust modern solution is a combination of: * Bayesian average for scalar ratings; * Bradley-Terry or Elo-style model for pairwise preferences; * confidence adjustment for low sample counts. Illustrative model: ```text score = 0.60 pairwise_strength + 0.30 bayesian_rating + 0.10 attribute_strength ``` Then calculate: ```text rank_score = score - uncertainty_penalty ``` The production algorithm should be treated as an experiment rather than immutable product doctrine. --- # 33. Charts Historically, highly rated music surfaced into genre charts. Microsoft described GarageBand.com's charts in 2004 as being generated from the site's listener-based review process. Required charts: ```text Overall Rock Electronic Hip-hop Pop Jazz Folk Metal Experimental etc. ``` Within each genre: ```text This Week This Month All Time Rising ``` --- # 34. Chart Eligibility Example: ```text minimum qualified reviews = 15 submission status = ranked moderation status = clean confidence threshold reached ``` An artist must not be able to purchase eligibility. --- # 35. Chart Page ```text ELECTRONIC # Track Artist Score 1 Neon Static Glass Radio 92.8 2 June Fires Orbit Room 91.6 3 Lines Carrion 90.2 ... ``` Each item should include: ```text play rating genre awards trend ``` --- # 36. Awards Awards were a major emotional-reward mechanism in GarageBand.com. Documented examples include: ```text Track of the Day Track of the Week Best Production Best Melody Best Guitars Most Original Best Programming Best Beat Best Mood ``` Artists actively publicised these awards outside GarageBand.com, showing they functioned as portable social proof. The clone should reproduce this effect. --- # 37. Award Engine Awards should emerge automatically from review evidence. Example: ```text Best Production eligibility: 20+ reviews metric: production score requirement: top 2% within genre/week ``` Possible awards: ```text Track of the Day Track of the Week Best Production Best Songwriting Best Vocals Best Performance Best Arrangement Best Mix Best Sound Design Most Original Best Melody Best Lyrics Best Rhythm Reviewer Favourite ``` --- # 38. Award Notifications Example: ```text Congratulations. "Neon Static" has been selected as Electronic Track of the Day. It will be featured on the Electronic chart for the next 24 hours. ``` Historical GarageBand.com sent messages of essentially this form and prominently featured award-winning tracks within genre pages. --- # 39. Public Review Display Track page: ```text REVIEWS ★★★★☆ Reviewer reputation: 91 "Strong arrangement and excellent low-end..." ``` Artist can choose: ```text show all reviews show selected reviews keep written feedback private ``` Numeric aggregated scores remain public once chart-eligible. --- # 40. Artist Review Dashboard For each submission: ```text Neon Static Overall 4.2 Production 4.6 Songwriting 3.9 Performance 4.0 Originality 4.7 Pairwise wins 68% Reviews 27 / 30 Chart #18 Electronic Highest #11 Electronic [ View reviews ] ``` --- # 41. Feedback Analysis Aggregate comments into recurring themes. Example: ```text MOST COMMON POSITIVE THEMES Production 17 mentions Bass sound 12 Atmosphere 9 Originality 8 MOST COMMON IMPROVEMENT THEMES Vocal level 11 Track length 7 Chorus impact 6 ``` AI may help categorise feedback. It must **not replace human feedback**. --- # 42. AI Policy AI may assist with: * toxicity detection; * spam detection; * duplicate review detection; * feedback categorisation; * summarising multiple reviews; * suspicious voting analysis; * genre classification. AI must not: * generate fake reviews; * listen on behalf of users; * fabricate feedback; * inflate review activity. The commercial value of this product depends on reviews representing **real human attention**. --- # 43. Discovery Mode After review evaluation, tracks become discoverable through conventional browsing. Discovery pages: ```text Home Charts Genres New Rising Award Winners Recommended Local ``` Discovery behaviour and review behaviour must remain conceptually separate. --- # 44. Music Player Persistent global player: ```text track artist play/pause seek volume queue like playlist artist profile ``` Public listening does not automatically count as formal review activity. --- # 45. Search Search entities: ```text artists tracks genres locations tags reviewers ``` Search must never influence controlled review allocation. --- # 46. Community Layer Possible features: ```text artist following reviewer following comments messages forums playlists collaborator discovery ``` These are secondary. Do not build them before the reciprocal review loop works. --- # 47. Fraud Threat Model The ranking system creates incentives to cheat. Assume users will attempt: * multiple accounts; * vote rings; * friend networks; * reciprocal high ratings; * bot reviewing; * minimal listening; * copy/pasted reviews; * AI-generated reviews; * targeted down-voting; * VPN/account farms. Fraud prevention is therefore part of the ranking architecture. --- # 48. Fraud Signals Record: ```text IP hashes device fingerprints session patterns review timing listening duration rating distributions pairwise relationships social relationships account age upload relationships payment relationships review-text similarity ``` Do not expose fraud thresholds publicly. --- # 49. Review Graph Analysis Model reviewers and artists as a graph. Detect suspicious clusters: ```text A highly rates B B highly rates C C highly rates A ``` especially when: * review allocation repeatedly coincides; * accounts share infrastructure; * ratings significantly deviate from population averages. --- # 50. Copyright Artists must affirm ownership or appropriate permission. Required flows: ```text copyright complaint counter-notification temporary removal repeat infringement handling ``` Audio fingerprinting can later detect duplicate commercial recordings. --- # 51. Moderation Moderation categories: ```text copyright hate/harassment threats spam sexual content fraud impersonation review abuse malicious feedback ``` A critical music review is not harassment merely because the artist dislikes it. --- # 52. Review Moderation Philosophy Permitted: ```text "The vocal performance feels pitchy and the chorus doesn't land." ``` Not permitted: ```text personal attacks against the musician threats identity-based abuse spam promotion ``` Moderation must protect honest criticism. --- # 53. Payments Historically, users could effectively exchange labour for submission access, while some eras offered paid shortcuts. A modern commercial model could offer: ### Free ```text Earn submission through reviewing ``` ### Paid submission ```text Pay monetary fee instead of earning credits ``` Important rule: > Payment purchases review capacity, never ranking. Paid and earned submissions must enter the same blind review pool. --- # 54. Revenue Model Potential revenue sources: ```text paid submission credits artist analytics advanced profile customisation private review campaigns professional reviewer panels industry scouting tools sync opportunities artist services subscriptions ``` Do not monetise: ```text chart position rating reviewer score awards pairwise outcomes ``` --- # 55. Marketplace Balance The core operational metric is: ```text review demand ÷ review supply ``` If: ```text demand > supply ``` tracks wait too long. If: ```text supply >> demand ``` reviewers lack work and credits become meaningless. The platform must actively maintain equilibrium. --- # 56. Dynamic Submission Cost Potential future mechanism: ```text submission_credit_cost = base_cost × queue_pressure ``` Example: ```text low review demand 15 credits balanced 20 credits high review demand 25 credits ``` Use cautiously. Predictability is valuable to users. --- # 57. Core Metrics ## Marketplace ```text reviews generated/day tracks submitted/day reviews demanded/day review supply/demand ratio median queue completion time ``` ## Review quality ```text median listening percentage average review length review usefulness score review invalidation rate ``` ## Artist value ```text percentage submissions completing evaluation median reviews/submission time to first review artist repeat-submission rate ``` ## Discovery ```text plays after review completion chart-to-play conversion award-to-play conversion artist follows generated ``` --- # 58. North Star Metric Recommended: > **Qualified human reviews completed per week** A qualified review means: * sufficient listening; * meaningful ratings; * acceptable written feedback; * no fraud indicators. Secondary north star: > **Percentage of submitted tracks receiving the promised review quantity within target time.** --- # 59. Activation Metric An artist is activated when they have: ```text completed first review AND received first review ``` This captures both halves of the marketplace. --- # 60. Retention Measure separately: ```text reviewer retention artist retention dual-role retention ``` The most valuable cohort will probably be: ```text artists who also regularly review ``` because these users keep the marketplace liquid. --- # 61. Notification System Events: ```text review received review campaign completed review rated useful credits earned submission eligible chart entered chart position changed materially award earned moderation action new follower ``` Avoid notifying artists after every minor rating fluctuation. --- # 62. Suggested Information Architecture ```text / ├── Home ├── Review │ ├── Start │ ├── Session │ └── History ├── Charts │ ├── Overall │ └── Genre ├── Discover ├── Artists ├── Tracks └── Account ├── Dashboard ├── My Music ├── Reviews Received ├── Reviews Written ├── Credits ├── Awards └── Settings ``` Primary navigation should prominently contain: **Review Music** GarageBand.com's historical navigation similarly treated reviewing as a first-class destination. --- # 63. Dashboard Artist dashboard: ```text ----------------------------------------------- GOOD EVENING, KEVIN ----------------------------------------------- REVIEW CREDITS 14 6 more credits to submit your next track [ REVIEW MUSIC ] ----------------------------------------------- YOUR MUSIC Neon Static Under Review 18 / 25 reviews completed Glass Houses #12 Electronic ★★★★★ 4.4 ----------------------------------------------- RECENT FEEDBACK "Fantastic intro..." "Kick feels slightly..." ----------------------------------------------- ``` --- # 64. Database Model Core entities: ```text users artist_profiles artist_members tracks audio_assets submissions genres submission_genres reviews review_scores review_feedback reviewer_reputation review_credit_transactions pairwise_comparisons ranking_snapshots charts chart_entries awards award_grants plays follows playlists playlist_tracks reports moderation_actions notifications ``` --- # 65. User Schema ```text users id UUID email username password_hash / auth_provider country_code created_at last_active_at status ``` --- # 66. Artist Schema ```text artist_profiles id name slug bio location avatar_url website_url created_at ``` An account may manage multiple artist identities. Therefore: ```text artist_members artist_id user_id role ``` --- # 67. Track Schema ```text tracks id artist_id title duration_ms audio_asset_id artwork_asset_id lyrics isrc release_status rights_status visibility created_at ``` --- # 68. Submission Schema ```text submissions id track_id primary_genre_id status credit_cost reviews_required reviews_received submitted_at completed_at ranking_score ranking_confidence ``` A track may theoretically undergo more than one review campaign over its lifetime. --- # 69. Review Schema ```text reviews id submission_id reviewer_id started_at submitted_at listening_ms listening_percentage overall_score text_positive text_improvement status reviewer_weight ``` --- # 70. Attribute Scores Do not add a column for every possible rating. Use: ```text review_scores review_id criterion_id score ``` and: ```text review_criteria id genre_id nullable name display_order ``` This allows criteria to vary by genre. --- # 71. Reviewer Feedback Schema ```text review_feedback id review_id artist_user_id usefulness listened_carefully specificity constructiveness created_at ``` --- # 72. Ranking Snapshots Never overwrite historical ranking. ```text ranking_snapshots submission_id score confidence genre_rank overall_rank calculated_at ``` This enables charts such as: ```text Highest position: #7 Current position: #31 ``` --- # 73. Awards Schema ```text awards id name metric period genre_specific ``` ```text award_grants award_id submission_id genre_id period_start period_end created_at ``` --- # 74. Audio Infrastructure Recommended architecture: ```text upload ↓ object storage ↓ malware validation ↓ audio validation ↓ transcoding ↓ waveform generation ↓ streaming derivatives ``` Store original uploaded file separately. Generate browser-compatible streams. --- # 75. Audio Security Use signed URLs or controlled streaming endpoints where necessary. Never expose raw storage paths. Track: ```text play start play stop seek completion review session ``` --- # 76. Backend Services Logical services: ```text Auth Service Artist Service Track Service Audio Service Review Queue Service Review Service Credit Ledger Ranking Service Chart Service Award Service Reputation Service Fraud Service Moderation Service Notification Service Search Service Analytics Pipeline ``` A small team should initially implement these as modules within a modular monolith rather than independent microservices. --- # 77. Recommended Initial Architecture ```text Web client ↓ API application ├── auth ├── artists ├── tracks ├── reviews ├── ranking ├── credits └── moderation ↓ PostgreSQL Redis Object storage Background worker Search index Analytics store ``` Do not begin with a distributed microservice architecture. --- # 78. Queue Infrastructure Two distinct queues exist. ### Infrastructure queue Background jobs such as: ```text transcoding emails ranking calculations notifications waveforms ``` ### Product review queue The logical marketplace determining which song a reviewer receives next. These should not be conflated. --- # 79. Review Allocation Endpoint Example: ```http POST /v1/review-sessions ``` Response: ```json { "session_id": "...", "submission": { "id": "...", "audio_url": "...", "duration_ms": 213000, "genre": "Electronic" }, "criteria": [ "Production", "Arrangement", "Originality" ] } ``` Artist identity omitted intentionally. --- # 80. Review Submission Endpoint ```http POST /v1/reviews ``` Conceptual payload: ```json { "session_id": "...", "overall_score": 4, "scores": { "production": 5, "arrangement": 4, "originality": 5 }, "positive_feedback": "...", "improvement_feedback": "..." } ``` Server validates listening telemetry independently. Never trust client-provided listening duration. --- # 81. Pairwise Endpoint After two reviews: ```http POST /v1/pairwise-comparisons ``` ```json { "submission_a": "...", "submission_b": "...", "preference": "submission_b" } ``` --- # 82. Ranking Jobs Ranking recalculation can occur: ```text after each qualified review ``` for individual scores, and: ```text every few minutes ``` for chart ordering. Historical GarageBand.com reportedly recalculated rankings as votes arrived. Modern systems can batch where necessary. --- # 83. Event Model Important internal events: ```text ReviewCompleted ReviewInvalidated ReviewRated CreditsEarned SubmissionCreated SubmissionReviewThresholdReached SubmissionRankChanged AwardGranted TrackReported ``` This will simplify notifications and asynchronous processing. --- # 84. Privacy Formal review mode should reveal as little reviewer identity as required. An artist might receive: ```text Reviewer #38427 Reviewer rating: 89 ``` rather than personal profile data. Historically GarageBand.com attempted to balance reviewer privacy with enough reputation information for artists to contextualise criticism. --- # 85. Accessibility The review experience must support: * keyboard controls; * screen readers; * visible focus states; * transcript/lyrics where supplied; * adequate contrast. Do not make waveform interaction the only means of controlling playback. --- # 86. Mobile Behaviour Reviewing music requires concentration. Mobile must therefore optimise for: ```text playback rating text entry continuous review sessions ``` Do not overload the review screen with public discovery features. --- # 87. MVP Scope The MVP should prove exactly one hypothesis: > Musicians will exchange meaningful listening and feedback through a reciprocal review economy. Build: ```text authentication artist profiles audio upload genre selection review credits blind review assignment audio listening telemetry star ratings written feedback review completion artist review inbox reviewer usefulness rating basic ranking genre chart moderation ``` Nothing more is required to validate the core product. --- # 88. Explicitly Exclude From MVP Do not initially build: ```text DMs forums mobile apps label marketplace sync marketplace advanced playlists livestreaming DAW integration collaboration tools NFTs music distribution social feeds complex subscriptions ``` All distract from the core hypothesis. --- # 89. MVP Success Criteria Example launch targets: ```text ≥90% submitted tracks reach review target median first-review latency <24 hours median campaign completion <7 days ≥70% reviews rated useful/somewhat useful ≥60% artists complete another review after receiving feedback ≥30% artists submit a second track ``` The exact figures are hypotheses. --- # 90. Phase Two After marketplace liquidity is established: ```text pairwise ranking advanced reviewer reputation awards Rising chart feedback summaries playlists following better discovery paid submissions ``` --- # 91. Phase Three Once strong music reliably emerges: ```text curator accounts industry scouting label tools radio/playlists sync discovery showcase opportunities professional feedback API ``` This recreates the second half of GarageBand.com's value proposition: ```text peer evaluation ↓ credible signal ↓ industry discovery ``` --- # 92. Critical UX Requirement: Do Not Become SoundCloud A conventional creator platform naturally becomes: ```text upload ↓ share link ↓ ask friends for plays ↓ social popularity ↓ algorithm rewards popularity ``` GarageBand.com's model was fundamentally different: ```text upload ↓ unknown strangers receive track ↓ identity concealed ↓ structured evaluation ↓ merit signal ↓ discovery ``` If users can drive their friends directly into the controlled review process, the system has failed. --- # 93. Critical UX Requirement: Do Not Become SubmitHub A curator marketplace is: ```text artist ↓ selects curator ↓ submits song ↓ curator evaluates ``` GarageBand.com's model is: ```text artist ↓ contributes reviews ↓ submits song ↓ platform selects peers ↓ many independent evaluations ``` The network itself creates the signal. --- # 94. Critical UX Requirement: Feedback Before Promotion Do not immediately push: ```text Share your track! Promote your release! Invite your followers! ``` Instead: ```text 18 of 25 reviews completed ``` The anticipation of genuine unknown listeners is one of the product's strongest psychological mechanisms. --- # 95. Why Users Participate The product contains several reinforcing motivations. ### Reciprocity ```text I listen because I want others to listen. ``` ### Curiosity ```text What will strangers think of my track? ``` ### Competition ```text Where will it rank? ``` ### Recognition ```text Can it win Best Production? ``` ### Improvement ```text What do people consistently dislike? ``` ### Discovery ```text What unknown music will I encounter? ``` ### Status ```text Am I becoming a respected reviewer? ``` Successful implementation should deliberately support all seven. --- # 96. Why the Historical Mechanism Worked The mechanism created a positive network effect unusual among creator platforms. Normally: ```text more creators = more competition for listener attention ``` Under GarageBand.com's model: ```text more creators = more potential reviewers = more available attention ``` Provided participants review before submitting, creator growth can partially produce the supply necessary to serve creator growth. That is the central economic insight worth rebuilding. --- # 97. Failure Modes ## Too many required reviews Users abandon before submitting. ## Too few required reviews Review supply collapses. ## Reviews too long Users optimise for completion or leave. ## Reviews too short Feedback becomes worthless. ## Ratings visible beforehand Reviewers become anchored by consensus. ## Artist visible beforehand Popularity, image and identity bias evaluation. ## Followers allowed to review directly Vote manipulation appears. ## Credits purchasable too cheaply The reviewer economy loses liquidity. ## AI reviews permitted The central promise of human attention becomes meaningless. ## Rankings opaque and unstable Artists lose trust. ## Rankings too deterministic Users game them. --- # 98. Historical Accuracy vs Modern Reconstruction The team should distinguish three categories. ## Historically verified Strong evidence supports: * artists reviewed other artists; * approximately 30 song reviews were required for submission by 2004–05; * tracks were assigned rather than chosen; * blind/random evaluation was used to discourage manipulation; * structured ratings were collected; * written feedback was collected; * reviewers themselves received reputation ratings; * songs entered genre charts; * awards were derived from reviewer responses; * high-ranking tracks received promotional exposure; * Creative Commons licensing became available; * the service explicitly considered peer review and ranking its central product. ## Historically supported but implementation details uncertain Evidence supports versions of: * Song A vs Song B comparisons; * proprietary ranking algorithms; * dynamically recalculated rankings; * exact review quotas varying by historical period; * precise award calculation. These should be reconstructed according to documented behaviour rather than reverse-engineered literally. ## Modern design decisions This specification introduces: * immutable credit ledger; * Bayesian ranking; * Bradley-Terry/Elo calculations; * listening telemetry; * fraud graph detection; * AI-assisted moderation; * modern audio streaming; * modular backend architecture; * dynamic review quality weighting. These are not claims about the historical implementation. --- # 99. Product Definition The shortest useful specification of the system is: > A musician earns the right to have strangers evaluate their music by first evaluating music from other strangers. Everything else follows. --- # 100. Minimum Fully Working Clone A system can reasonably call itself a functional recreation of GarageBand.com's defining experience when this exact journey works: ```text 1. Alice registers. 2. Alice creates an artist profile. 3. Alice tries to submit a track. 4. The system tells Alice she needs review credits. 5. Alice chooses Electronic. 6. The system anonymously assigns Alice Bob's track. 7. Alice listens. 8. Alice rates and reviews Bob's track. 9. Alice repeats this process until enough credits exist. 10. Alice uploads her own track. 11. Alice spends her credits and submits it. 12. Alice's identity is hidden from reviewers. 13. The system assigns her track to multiple unrelated reviewers. 14. Reviewers listen and provide structured ratings and written feedback. 15. Alice receives those reviews. 16. Alice rates whether each review was useful. 17. Those ratings influence reviewer reputation. 18. Alice's song receives a statistically meaningful score. 19. The song enters its genre chart. 20. Strong individual dimensions may generate awards. 21. Other listeners discover Alice's track because it performed well. 22. Alice reviews more music to submit another track. ``` If that loop is compelling, the product works. If that loop is not compelling, playlists, social feeds, label integrations and advanced AI features will not rescue it. --- # 101. Recommended Product Positioning Avoid describing the service as: > A social network for musicians. Prefer: > **Where musicians actually listen to each other.** Alternative: > **Get your music heard. Earn it by listening.** Or more functionally: > **Real feedback from real musicians.** The product should be understood immediately as a solution to the question: > “How do I get unbiased people to genuinely listen to my track?” --- # 102. Initial Developer Milestone The first internal milestone should contain only: ```text User A uploads track ↓ User B receives it anonymously ↓ User B listens ↓ User B writes structured review ↓ User B earns credit ↓ User A receives review ↓ User A rates review quality ``` No charts are necessary yet. No discovery system is necessary yet. No payments are necessary yet. If this seven-step interaction feels valuable to both participants, proceed. --- # 103. Final Product Principle GarageBand.com's enduring insight was not its website design, branding, MP3 hosting or even its charts. It recognised that the scarce resource in independent music is **not storage**. It is **attention**. Storage became effectively free. Distribution became effectively free. Publishing became effectively free. Attention did not. The rebuilt product should therefore treat attention as a finite resource that users: * contribute; * earn; * exchange; * measure; * reward. That principle should inform every significant product decision. --- # Appendix A: Historically Documented GarageBand.com Characteristics | Behaviour | Evidence level | | -------------------------------------- | --------------- | | Musicians reviewed other musicians | Strong | | Review required before submitting | Strong | | ~30 songs required circa 2004–05 | Strong | | Tracks randomly/automatically assigned | Strong | | Blind evaluation | Strong | | Written reviews | Strong | | Numerical ratings | Strong | | Pairwise comparison | Strong/moderate | | Genre separation | Strong | | Reviewer ratings | Strong | | Artist evaluates review usefulness | Strong | | Genre charts | Strong | | Merit-oriented rankings | Strong | | Awards | Strong | | Track of the Day | Strong | | Track of the Week | Strong | | Free MP3 downloads | Strong | | Creative Commons option | Strong | | Industry discovery objective | Strong | --- # Appendix B: Core Domain Language Use these terms consistently throughout code and product documentation. **Track** An uploaded recording. **Submission** A track entered into formal peer evaluation. **Review** One reviewer's structured evaluation of one submission. **Review Session** The controlled interaction during which a reviewer listens and evaluates music. **Review Credit** An accounting unit earned through qualified reviewing and spent to submit music. **Reviewer Reputation** A measure of the demonstrated quality of a user's reviewing behaviour. **Pairwise Comparison** A preference decision between two submissions. **Ranking Score** The internal statistical measure derived from review evidence. **Chart Position** A submission's relative placement within a defined ranking period/category. **Award** Recognition automatically generated from exceptional review evidence. **Qualified Review** A review satisfying listening, content, quality and fraud requirements. --- # Appendix C: Source Notes The reconstruction above is based primarily on contemporary or preserved material rather than later recollection. Important sources include: * January 2005 interview with GarageBand.com CEO Ali Partovi describing the 30-song review requirement and identifying the review/ranking system as the core of GarageBand.com. * 2004 Wired coverage confirming musicians rated 30 other songs before uploading. * Preserved GarageBand.com help documentation explaining why musicians were required to review and confirming predetermined review coverage for submitted tracks. * Preserved GarageBand.com reviewer-rating FAQ quoted contemporaneously in September 2003. * Contemporary Guardian description of randomly assigned reviews, anti-ballot-stuffing design, genre separation and statistically driven rankings. * GarageBand.com launch material describing its proprietary comparison/ranking engine. * Microsoft 2004 announcement describing listener-review-derived GarageBand.com charts and radio exposure. * Creative Commons' 2004 description of listeners comparing song samples and unsigned artists receiving feedback and ratings. * Contemporary user accounts from 2003 and 2005 describing review requirements and reviewer evaluation. * Surviving artist records documenting GarageBand.com awards including Track of the Day, Best Production, Best Programming, Best Melody, Most Original and similar categories. --- # Appendix D: One-Sentence Engineering Brief **Build a blind reciprocal music-review marketplace where musicians earn submission capacity by providing qualified reviews, every submitted track receives controlled peer evaluation, reviewers develop reputations, and statistically strong tracks emerge into genre charts and awards.**