FRP SPINS: Modernizing a 720,000-Track Shazam-Style Platform for Professional DJs

What we shipped, in one paragraph

Fora Soft took Franchise Record Pool (FRP) — a 720,000-track Shazam-like service for professional DJs — from an outdated single-website product into a four-surface ecosystem: a redesigned web app, React Native iOS and Android apps, and an Electron desktop app for Mac and Windows. We added two features DJs had been asking for years: a Shazam-for-remixes recognition engine that finds every version of a track in under two seconds, and an AI voice-playlist assistant that accepts a natural-language brief like “Italian pop, 90s, 140 BPM” and returns a ready-to-play set. This article is the companion to our FRP build guide — where that one covers architecture and cost for someone starting from zero, this one covers the improvement pass we ran on an already-live platform and the UX decisions that made professional DJs switch from the old client to SPINS in six weeks.

Why the old FRP had to be rebuilt

FRP had been live for years with a loyal base of professional DJs, but three problems were compounding. First, the UI predated the smartphone era: track cards crammed eight data points into a row that looked fine at 1440px and collapsed into illegible chips at 768px. Second, there was no native client — DJs working pre-show on an iPad or grabbing a last-minute track from a phone had to load the desktop website in mobile Safari, which made the download flow painful. Third, the catalog had grown past half a million tracks, but the search was still a plain SQL LIKE query — fine for titles, useless for “songs that sound like this one” or “every remix of this master.”

The founders came to Fora Soft because we had already built audio-streaming products at scale (our streaming services page has the list) and we’d published a prior case showing how we handle licensed catalogs. They didn’t want a rewrite. They wanted a clean UX pass, native clients, and two specific new capabilities: Shazam-style recognition and AI playlist generation.

The professional DJ workflow we designed for

Before we redrew a single screen we shadowed four working DJs for a week — two club residents in New York, a mobile wedding DJ in Dallas, and a Serato-based radio host in London. The workflow we saw was the same every time: scout the pool two or three evenings a week, batch-download twenty to forty promising tracks per session, pull them into Serato or rekordbox for analysis, then audition and cull the night of the gig. Speed of scouting mattered more than visual polish — nobody was going to stop to admire a card animation when they were behind on a 90-minute prep window.

What they repeatedly asked for: BPM, key and energy level visible without hovering or clicking; the ability to hear a 30-second preview with one tap; a way to find “every version of this song” (clean, dirty, acapella, instrumental, remixes); and a folder sync that just worked with the way their DJ software already read files. We built to those four needs and left the rest alone.

The complete UI redesign — what changed and why

The old UI hid decision-making data under hover states. The new UI shows it. We moved to a dense row layout with four always-visible data columns — title and artist, genre and sub-genre, BPM and key, and a single action button that expands into download / preview / add-to-playlist. The grid was built in a 12-column system so it degrades cleanly to 8 columns on tablet and stacks to a card layout on mobile without anything disappearing.

Navigation moved from a sidebar tree into a persistent top bar plus a contextual rail. Four primary destinations: Catalog, Playlists, Downloads, Settings. Everything else became search-first, because our usage data showed that more than 70% of sessions opened with a search query anyway. We rebuilt filters as chip-style pills (label + bpm range + key + year + exclusivity tier) so applied filters are always legible without opening a modal.

Track library: surfacing BPM, key and sources that matter

The catalog covers 720,000 licensed tracks from Sony Music, Universal, Virgin and dozens of indie labels. On the old platform every track carried rich metadata — BPM, key, genre, sub-genre, year, label, mix type, exclusivity window, source files — but the UI rendered it as one paragraph. DJs skipped over it. We restructured the detail panel into three zones: decision data at the top (BPM, key, energy), creative context in the middle (label, year, release tier), and operational data last (file formats, download history, remix tree).

The remix tree is the piece that changed the most. On the old site, clicking “see all versions” returned a flat list. We replaced that with a visual tree: the master at the top, clean and radio edits as one branch, all remixes as siblings with the remixer’s name and BPM next to each. DJs who had been using the site for years told us this alone was worth the redesign — they finally knew a remix existed without having to search for it.

The SPINS ecosystem: web + desktop + mobile as one app

Before this project FRP existed only as a website. We built three new clients around it and gave the bundle a shared product name — SPINS — so DJs understood they were getting one product on four surfaces, not four disconnected tools. A playlist you create on the iPhone appears on the desktop app within seconds. A track you downloaded on Windows is already sitting in the Serato folder on your Mac if you’re signed into both. That state synchronization was the part that took the longest to get right.

All four clients hit the same GraphQL API and share a subset of the same React-based component library. Design tokens (color, type scale, spacing) live in a single repo, imported by every client. When the design team tweaks a spacing rule, the web app, desktop app and both mobile apps pick it up on their next build.

React Native mobile apps — iOS and Android

We chose React Native because FRP’s web team already wrote React and the deadline was tight. Upside: roughly 85% code shared between iOS and Android, one team, one test suite. Downside: we had to write two native modules — one for background downloads that survives the app being backgrounded on iOS, one for the audio graph so we could crossfade preview clips without the React thread dropping frames.

The mobile flow is scout-heavy: a DJ browses during a commute, stars tracks, and the desktop app downloads them automatically the next time it’s online. That star-queues-for-download pattern was the single most-used feature after the first month. We never originally shipped download-on-device as a primary path — nobody mixes from a phone — but we did ship offline previews so you can audition starred tracks without a signal. See our custom software development services for how we staff a React Native team alongside web and backend.

Electron desktop app for Mac OS and Windows

The desktop app is where DJs do the actual work: bulk download, folder sync, Serato drag-and-drop, chat with other DJs in the pool. We built it in Electron with a thin native layer for filesystem watchers and for the system-tray minimize behavior DJs expect. The chat feature runs on the same WebSocket infrastructure our video-streaming clients use — adding it was a day of work once we wired in our existing streaming stack.

One counter-intuitive choice: we deliberately kept the desktop app feature-lean relative to the web app. Downloads, playlists, chat, settings. That’s it. Everything discovery-related happens on the web or on mobile. The argument was that a DJ in the middle of a mix wants the desktop app to be a fast, quiet file manager — not another place to discover music.

Music recognition — the Shazam-for-remixes feature

The recognition engine solves a problem no consumer Shazam tackles: it matches remixes, bootlegs and edits against their master. A DJ who hears an unfamiliar bootleg at a club can hum or record ten seconds on their phone, drop it into SPINS, and we return every remix branch in the catalog that shares the same master — usually including the clean version, the dirty version, a radio edit, and half a dozen remixes. That is not something a consumer app does.

Under the hood the engine uses a Shazam-style constellation algorithm on peak-frequency landmarks, but trained on the remix tree, not just the master. Every fingerprint in the index carries a link back to the master and the sibling remixes, so a match returns the full family, not a single row. The technical build is covered in depth in our FRP build guide — this piece focuses on why the UX felt like magic and not like a search.

AI voice playlists — “Italian pop, 90s, 140 BPM”

You hold a microphone button, say what you want, release. SPINS parses the spoken brief, converts it into a structured query over the catalog’s metadata (genre, sub-genre, era, BPM range, key compatibility), adds a mood vector from Essentia-derived features, and returns a 20-track starter set you can save, shuffle or edit. The whole round-trip is under four seconds on a good connection.

We built the voice intake on OpenAI’s Whisper ($0.006 per minute of audio, so negligible) and the brief-to-query layer on GPT-4o with a strict JSON schema. The playlist-selection logic is our own — it mixes the LLM’s candidates with a BPM-coherence pass so every adjacent pair of tracks is within ±3 BPM and a compatible Camelot key. DJs told us this was the difference between “interesting playlist” and “playlist I can actually mix from.” If you want to add this kind of voice layer to your own product, our AI integration services is the place to start.

Chat, folder-sync and Serato drag-and-drop

DJs asked for three small features that turned out to move retention more than any flagship addition. First, a chat channel inside the desktop app where DJs in the pool can DM each other and share pool-internal remixes. Second, configurable download folders that mirror the structure Serato and rekordbox scan for — so a downloaded track appears in the DJ’s software without them moving a file. Third, drag-and-drop from the SPINS desktop app directly into an open Serato window, which Electron supports natively but required polishing on Windows.

These are the features that made switching from the old FRP client feel like getting a better tool, not learning a new one. Every interview we did post-launch mentioned folder sync by name.

Architecture of the multi-platform system

All four clients (web, desktop, iOS, Android) speak to a single GraphQL gateway that fans out to five backend services: Catalog (read-heavy, Postgres plus a Redis cache for hot-track lookups), Identity (Cognito behind a thin wrapper), Downloads (job queue backed by SQS), Recognition (the fingerprint matcher, Go plus FAISS), and Playlists (the voice-brief-to-query pipeline). Storage is S3 for source audio, CloudFront for preview streaming, and a separate transcoded-preview bucket because preview traffic is 20× the download traffic.

State sync between clients runs on a WebSocket channel per user — when you star a track on mobile, the desktop app sees a push and pulls the updated playlist within a second. We explicitly did not try to build a CRDT system; for a user whose four clients are nearly always under their control, last-writer-wins with a server-authoritative truth is fine and two orders of magnitude simpler to operate.

Audio fingerprinting at 720,000-track scale

The catalog holds 720,000 tracks, each fingerprinted into roughly 500 peak-pair landmarks (we tuned for density that balanced recall vs index size). That’s about 360 million landmarks in the index. FAISS IVF-PQ gets us sub-100ms nearest-neighbor lookups on a single c6i.8xlarge; we shard the index by genre primarily for cache locality, not for capacity.

A 10-second query fingerprint is sent from the client to the recognition service, matched against the index, then filtered through a temporal-consistency check: we only trust a match if at least 40% of the landmark pairs line up in time-offset space, not just in absolute count. That’s the difference between a track that genuinely shares a master and two tracks that happen to have similar kick drums.

The metrics that moved after launch

We tracked four headline metrics for the first 90 days post-launch and compared them to the 90 days before: time-to-first-download per session, tracks previewed per session, weekly active DJs, and paid-plan conversion.

How we migrated a live platform without downtime

FRP was never switched off during the rebuild. We ran old and new in parallel for six weeks, migrating users a cohort at a time and keeping a shared database under both so a DJ’s playlists, download history and saved tracks worked in either client. When a cohort moved to the new UI, the old UI stayed reachable under /legacy for two more weeks in case they wanted to roll back. Nobody did after day 10.

The one piece we migrated hard was the search backend: the old LIKE-query stack was deprecated on day one for the new cohort. Rolling it back would have required the old UI to point at a search service that no longer existed. We accepted that risk in exchange for a cleaner cutover; the alternative was keeping two search stacks in production for months.

Five lessons from improving a professional DJ tool

Lesson 1: information density beats visual polish. A pro DJ working a pre-show set doesn’t want a spacious, breathable interface. They want seven data points in a scannable row. We spent two weeks stripping whitespace back out of the initial redesign.

Lesson 2: the feature users rave about is rarely the headline feature. Music recognition got the press; folder sync got the retention. Both matter — but if you have to pick one to invest in, pick the quiet one that solves daily friction.

Lesson 3: for a multi-platform product, share design tokens first, then components. We got four clients to feel like one product largely because color, type and spacing came from one place. Only 30% of components are actually shared.

Lesson 4: ship AI as a workflow assist, not a replacement. The voice-playlist feature is popular because it saves ten minutes of manual filtering, then hands the DJ a playlist they still get to edit. If we’d tried to auto-play the generated set, DJs would have distrusted the feature within a week.

Lesson 5: run old and new in parallel longer than feels necessary. We kept the legacy client live for two weeks after every cohort migrated. It cost almost nothing to run and bought us immense goodwill from power users who were nervous about a rebuild.

Cost to rebuild a similar ecosystem in 2026

Rough order-of-magnitude ranges for a product with an existing catalog and customer base, modernized the way we modernized FRP. These assume you already have the licensing, storage, catalog metadata and a working backend — the cost here is the UX rebuild, the native clients, and the two AI features.

Total ballpark: $460k – $635k over roughly six calendar months, assuming workstreams run in parallel where the dependencies allow. We price below most US and Western European agencies of comparable quality because our senior team is based in Eastern Europe and UAE. You can check current ranges on our custom software development page.

When to hire Fora Soft vs build in-house

Hire Fora Soft when you have a live product with real users, you want to modernize without stalling the roadmap, and you don’t have a full native-mobile + audio-streaming team in-house. We’ve shipped six music and audio products of comparable complexity and can plug in within three weeks.

Build in-house when you already have the domain depth — a mobile lead who’s shipped a React Native app, a DSP engineer for the recognition side, and an existing design system you trust — and the modernization is small enough that onboarding an agency costs more than it saves.

FAQ

What to read next

Ready to modernize your own audio product?

Fora Soft rebuilt FRP into a four-surface SPINS ecosystem with Shazam-style recognition and AI voice playlists — and moved paid conversion by 34% without a day of downtime. If you’ve got a live audio product that needs a similar pass, we’ll run the discovery, send you a fixed estimate inside two business days, and start within three weeks.