Spotify locked down their API, so I built an affordable alternative for indie devs (90M tracks, open beta)
A while back I was building DJ tooling and kept hitting the same wall: I'd have a track on one platform and need the same track everywhere else — the Apple Music link, the Tidal ID, the Beatport release — plus clean metadata (label, release date, genre). There's no single, affordable place to get that.
Then Spotify started locking down their API — the default for anyone building a music app. Audio features, related artists, previews: gone or gated unless you're a big company. That kills it for indie devs, hobbyists, and bootstrappers.
So I built SonoVault (https://www.sonovault.now). It aggregates open catalog data (Discogs, MusicBrainz, Wikidata, MLC) and enriches it with cross-platform IDs — ~90M tracks. You can search, browse by genre/year/label, pull artist info (origin, socials), and resolve any ISRC or platform ID to links on every platform in one call.
The hardest part was deduping. The same recording shows up as a dozen near-identical rows across sources (radio edit, extended mix, remaster, reissue), each with its own ID and often its own ISRC. SonoVault collapses those into one canonical track — so search returns one clean result instead of fifteen, but every ISRC still resolves back to it. Getting that right without merging genuinely different tracks took a lot of iterations.
It's in open beta — free tier is 1,000 req/mo, no credit card, and I'm happy to bump limits for free for anyone who wants to stress-test it.
This is a strong wedge because the pain is not just metadata.
It is indie music-app builders losing reliable access to the platform layer they were depending on.
I’d be careful not to let SonoVault sound like a large catalog database only. The sharper frame is probably “music metadata and cross-platform ID infrastructure for indie devs after Spotify’s API lock-down.”
That makes the urgency clearer.
The real beta signal I’d watch is whether devs use it for an actual workflow: track matching, catalog enrichment, DJ tooling, playlist migration, or rights/metadata cleanup. Curiosity around 90M tracks is nice, but repeat API usage around one workflow is the real signal.
Absotelutely, you don't need crazy many features but you do need a stable catalog with the music people are looking for. Spotify has 300M tracks but a lot of that is garbage, white noise, AI music so less is actually more for a music database I would say.
How devs are going to use Sonovault I don't know yet but I'm curious to see where it goes!
That makes sense.
The “less but cleaner” angle could actually be part of the positioning, especially if SonoVault becomes the stable layer devs use when Spotify data gets noisy or restricted.
I’d just be careful not to wait too long to see “where it goes.” The earlier you identify one repeat workflow, the easier it becomes to shape the beta around real usage instead of general curiosity.
If useful, share your email and I’ll put the tighter beta-workflow angle together properly.