Personal-network home-library streaming for DJs with local-only tracks
A self-hosted mobile client that lets DJs and collectors stream their own local music library (tracks not on Spotify/Apple Music) from home to phone without cloud upload or manual syncing.
People describe the problem, but nothing on file shows them paying to solve it. That gap is the thing to test first.Evaluated Aug 11, 2026 · thresholds published at /methodology
Supporting evidence3
A user with years of accumulated local-only music explicitly wants mobile access without moving files to cloud services or rebuilding catalogs.
DJs are actively frustrated with the dominant library tool (Rekordbox), citing instability and corruption, suggesting appetite for an alternative library manager.
Existing tooling for exposing a home network device (Tailscale, QUIC-based transports like Iroh) already solves the hard networking problem, lowering build difficulty for a client that layers streaming UX on top.
Falsifying evidence4
Only two signals support this cluster, both from a single source (Hacker News), so demand outside a niche technical audience is unverified.
Spotify and Apple Music are named as the platforms that fail these users, but neither has a documented incentive or record of building local-library support, meaning the market may simply be un-served rather than open — it could also mean the audience is too small for them to bother, which cuts both ways.
No verified revenue exists for any of the five referenced products (Spotify, Apple Music, Iroh, QUIC, Tailscale) in this cluster, so there is no proof point that adjacent tooling monetizes this specific need.
The underlying complaint is partly about Rekordbox's reliability, not about mobile access per se — a founder could build the wrong product if the real pain is library corruption rather than remote streaming.
Most likely cause of death
The founder builds a slick home-to-phone streaming client using Tailscale/QUIC-style networking, but discovers the actual DJ audience cares more about gig-reliable library management (the Rekordbox pain in S-2030) than remote listening from a couch, and the enthusiast audience (S-45) is too small and too technical to pay for a hosted or app-store product when they could self-host a free alternative like Plex or Jellyfin. Defensibility would need to come from DJ-specific workflow features (crate/cue integration, USB export parity) rather than generic personal media streaming, which is a crowded, largely free-alternative space.
Demand ladder
A complaint is not a customer. Weighted ×1 / ×3 / ×8 / ×15.
Verified revenue: none on file for this problem yet. That is an absence of records, not proof nobody is earning here.
Momentum
Is this problem getting louder or quieter?
Saturation
How many people are already on it. Most sites hide this.
Problem evidence
Who feels this, how often, and why what they use today does not fix it.
- Who feels it
- DJs and serious collectors whose libraries contain tracks (promos, unreleased edits, rips, bootlegs, self-produced material) that do not exist on Spotify or Apple Music, and who therefore only hear that music at the desk where the files live. A second, overlapping group: performing DJs who must run Rekordbox to prepare USB drives for Pioneer CDJs and find that software unstable.
- How often
- Unknown from this block. Listening away from the desk is plausibly daily for the collector in S-45; Rekordbox library prep is per-gig for the DJ in S-2030. Neither signal states a frequency, so treat both as inferred.
- Why current fixes fail
- The two fixes on offer both cost something the user refuses to pay. (1) Cloud: uploading a multi-hundred-GB library of unreleased, promo and bootleg material to a locker service means rebuilding a catalog that already has years of manual curation, tag work and folder logic in it, and putting undistributed material on someone else's servers — S-45 explicitly frames the constraint as 'without moving files to cloud services or rebuilding catalogs'. (2) Manual sync: copying subsets to a phone means deciding in advance what you'll want, which is exactly the decision a large library exists to avoid. Meanwhile the DJ-side failure is a different failure: Rekordbox is the mandatory bridge to CDJs, and when it corrupts or slows the library, the damage lands in the hours before a gig while exporting to USB — remote streaming does not touch that moment at all. So the person with the loudest pain (S-2030) is not the person the streaming product serves (S-45).
Collectors with local-only music cannot reach their own library from a phone without either uploading to a cloud service or rebuilding their catalog, and refuse both.
The material in question is specifically not on Spotify or Apple Music, so a subscription streaming service does not substitute for it.
Performing DJs are compelled to use Rekordbox because it is the required path to loading music onto USB for Pioneer CDJs, and they describe it as clunky, slow to load music, and prone to corrupting libraries.
The stronger of the two signals (severity 75) is about library reliability and export, not about mobile or remote access — the two pains are adjacent, not the same, and building for one may not serve the other.
Both signals come from Hacker News only; there is no forum, subreddit or app-store evidence in this block, so the pain is verified for a technical audience and unverified for working DJs at large.
No signal in this block shows anyone paying, having paid, or asking where to pay for remote access to their own local library. Demand tier for both records is complaint/intent, never spend or revenue.
The users already name the exact networking primitives a solution would use (Tailscale, QUIC, Iroh), which indicates they are capable of assembling the fix themselves and lowers willingness to pay for a packaged one.
Neither Spotify nor Apple Music has any documented move toward local-library support in this block, which can mean the niche is unserved or that it is too small to serve; the evidence does not distinguish.
Who buys it
The person who feels the pain and the person who signs are rarely the same.
Who buys it is part of membershipThe buyer, the budget it comes out of, and what these people already pay for.Product concept and MVP
Two versions: the one you deliver by hand first, and the one you build.
Product concept and MVP is part of membershipThe concierge version, the buildable version, and the features deliberately left out.Competitors and alternatives
Including the free workaround people use today, which is usually the real competitor.
Competitors and alternatives is part of membershipDirect products, indirect ones, the workarounds, and where the gap actually is.Pricing model
modelledA proposal, not an observation. Benchmarks come from the data; the ladder is ours.
Pricing model is part of membershipA tier ladder with the reasoning behind each price point.Revenue scenarios
modelledArithmetic on the assumptions listed underneath. Change an assumption and the number changes.
Revenue scenarios is part of membershipBase, upside and aggressive cases with every input written out.Market size
modelledReachable customers, not a top-down industry figure.
Market size is part of membershipHow many buyers exist, what they spend, and how many you could realistically reach.Go to market
Named places, not channel categories. These signals came from somewhere.
Go to market is part of membershipWhere the first ten customers come from, then the first hundred.Roadmap
Each version ships something a user can use. No infrastructure-only phases.
Roadmap is part of membershipVersion by version, with what belongs in each.Pivot paths
Where this goes if the first version does not land — and the number that says it did not.
Pivot paths is part of membershipAdjacent directions, and the measurable trigger for taking one.Risks and kill criteria
The thresholds at which the honest move is to stop. Written before you are attached to it.
Risks and kill criteria is part of membershipRanked risks, and the numeric conditions under which to walk away.Validation plan
Seven days that cost nothing but time and can kill the idea before you build.
Validation plan is part of membershipA day-by-day plan and the interview questions that do not lead the witness.Sources and freshness
Every reference opens the original post. This is the part you should check first.
How sure are we, per claim
Where the data is thin, we say so instead of rounding up.
- demand
- Low
- payment
- No data
- market size
- Low
- competitor gap
- Low
11 references from 2 signals · evaluation written Aug 11, 2026.
Related opportunities
Nearest by what the problem actually is, not by category label.
Offline-first time clock and job schedule for rural field service crews
A mobile time-tracking and scheduling app for field service technicians that fully functions without cell signal, syncing entries when connectivity returns.
Unified web-parity mobile client for SimplePractice/Jane clinics
A mobile booking app for small clinics that mirrors the clinic's web portal exactly — same login, same appointment history, same payment info — for practices running SimplePractice or Jane.
Third-party calibration app to suppress false theft-lock triggers during running (Android)
A companion app for Android runners that detects a 'run session' (via connected earbuds/watch or manual toggle) and temporarily suppresses Google's theft-detection lock so it stops mistaking running for a phone snatch.
Eleven more sections behind this one
Who signs the cheque, what the space already charges, the seven-day validation plan, and the thresholds at which you should stop. Three ideas are open in full so you can judge the depth before paying.
0 people have looked at this · 0 turned it into a spec · 0 say they're building it