Good Faith
Phase 1 royalty pipeline complete; self-hosted via Docker Compose (outcomes not measured yet)
For indie label operators (~5–50 artists) who need multi-distributor royalty consolidation without switching distributors or paying a percentage of earnings.
At a glance
- Role
- Creator and technical lead (solo)
- Timeframe
- Jul 2026 – present (research Jul 4 2026; repo Jul 4 – Oct 11 2026, 30 commits)
- Team
- Solo
- Users
- Indie label operators self-hosting (qualitative; no adoption numbers published)
- Status
- Active, self-hosted. Phase 1 royalty pipeline complete; other modules are in-app trackers.
- Stack
- Next.js 16, React 19, Django 6, PostgreSQL 16, Celery, Redis; Docker, Railway + Vercel; AGPL-3.0
Problem and stakes
Indie labels live in Google Sheets until multi-distributor royalties break them. Existing tools force a distributor switch, take a percentage of earnings, or target solo DIY artists or enterprise.
Market research on Jul 4 2026 (24+ competitor platforms, 200+ features across 20 modules, 9 Reddit threads across 7 subreddits) found the top functional need was consolidating royalty statements across distributors, and the key psychological barrier was fear that a tool will shut down or change—forcing labels to relearn a new system and risking their data.
From r/WeAreTheMusicMakers: “These websites with their own programs or interfaces are pretty — but if they ever close or do a major update of the program, it could really screw things up.”
From r/recordlabels: “The bigger issue with accounting is that we also manage artists under different distributors and it becomes a problem when combining royalty statements from different distributors into one spreadsheet.”
Integration sprawl is illustrated by Reprtoir’s integrations page (https://www.reprtoir.com/integrations): 80 integrations across 10 categories (distributors, DSPs, PROs, neighboring rights, metadata, analytics, and more).
Constraints
Solo builder; AGPL-3.0 and self-hosting as product constraints (no SaaS billing, never a cut of earnings). Must stay distributor-agnostic and prove data portability before labels will trust the system.
Options considered
Reprtoir was the main incumbent studied and used as the feature benchmark/catalyst. Other tiers studied: royalty specialists (e.g. Curve), distribution-plus-label tools (FUGA, Label Engine, DistroKid label plans). Spreadsheets remain the real incumbent.
Decision
Build it open-source and self-hosted with guaranteed full JSON/CSV export so a label can never be stranded; flat (free) instead of percent-of-earnings; distributor-agnostic ingestion; role-based access enforced in the API.
Program plan
Build order: Platform → Catalog → Royalties → Splits → Payments → Artist portals → Contracts → Publishing → Distribution → Analytics.
Technical system
Django apps: accounts, catalog, royalties, splits, payments, audit, notifications, contracts, publishing, dam, distribution, erp, analytics, ar, sync, marketing, workflow, core.
Statement upload → Celery processing with a shared pandas parser and per-distributor header aliases for DistroKid, TuneCore, CD Baby, Symphonic, ONErpm, RouteNote, TooLost, FUGA, Vydia, The Orchard → normalized royalty run → 100% split sheets → payout batches, ACH CSV, PDF statements.
Roles Artist/Manager/Finance/A&R/Admin enforced in the API; A&R has no royalty access. Mandatory TOTP 2FA for Manager/Finance/Admin before financial endpoints. Append-only (API/admin) audit log of royalty and payout actions. Full label export as JSON or CSV ZIP. Optional S3/R2 storage.
Execution
Shipped Phase 1 following the build order above. Oct 2026 multi-tenant and finance-endpoint hardening (PR #1 on the goodfaith repo).
Outcome
Outcomes not measured yet. Phase 1 is complete and installable via docker compose with demo seed.
Reflection
Ops modules (contracts, publishing, distribution, marketing, etc.) are honest trackers today—not full workflow engines. Next steps: deeper parsers and tests per distributor, CWR/PRO export, and DSP delivery.