FRP SPINS: как мы модернизировали Shazam-платформу на 720 000 треков для профессиональных диджеев

Что мы сделали — в одном абзаце

Фора Софт превратила Franchise Record Pool (FRP) — Shazam-подобный сервис для профессиональных диджеев с библиотекой из 720 000 треков — из устаревшего продукта-одного-сайта в экосистему из четырёх продуктов: переработанное веб-приложение, мобильные приложения на React Native для iOS и Android и десктопное приложение на Electron для Mac и Windows. Мы добавили две функции, о которых диджеи просили годами: движок распознавания «Shazam для ремиксов», который находит все версии трека меньше чем за две секунды, и голосовой AI-ассистент для плейлистов, который принимает запрос на естественном языке — например, «итальянский поп, 90-е, 140 BPM» — и возвращает готовый к проигрыванию сет. Эта статья — спутник нашего гайда по созданию FRP: там разбираются архитектура и стоимость для тех, кто стартует с нуля, а здесь мы рассказываем про этап улучшений, который мы провели на уже работающей платформе, и про UX-решения, которые заставили профессиональных диджеев перейти со старого клиента на SPINS за шесть недель.

Почему старую FRP пришлось перестраивать

FRP работала уже несколько лет и имела лояльную базу профессиональных диджеев, но три проблемы накапливались одновременно. Первая: интерфейс был родом из эпохи до смартфонов — карточки треков втискивали восемь параметров в один ряд, который нормально смотрелся на 1440px и превращался в нечитаемую кашу на 768px. Вторая: не было нативного клиента — диджеям, которые готовились к выступлению на iPad или хватали трек в последнюю минуту с телефона, приходилось открывать десктопный сайт в мобильном Safari, и процесс скачивания превращался в мучение. Третья: каталог вырос за полмиллиона треков, но поиск по-прежнему был обычным SQL-запросом с LIKE — годным для названий и бесполезным для «песен, которые звучат как эта» или «всех ремиксов этого оригинала».

Основатели пришли в Фора Софт, потому что мы уже создавали аудиостриминговые продукты на большом масштабе и публиковали разбор предыдущего кейса о том, как мы работаем с лицензированными каталогами. Они не хотели переписывать всё с нуля. Им был нужен аккуратный апдейт UX, нативные клиенты и две конкретные новые возможности: распознавание в духе Shazam и генерация плейлистов с помощью AI.

Рабочий процесс профессионального диджея, под который мы проектировали

Прежде чем перерисовать хоть один экран, мы неделю наблюдали за работой четырёх действующих диджеев — двух клубных резидентов из Нью-Йорка, мобильного свадебного диджея из Далласа и радиоведущего из Лондона, работающего на Serato. Рабочий процесс везде был один и тот же: прочёсывать пул два-три вечера в неделю, пакетно скачивать по двадцать-сорок перспективных треков за сессию, затем загружать их в Serato или rekordbox для анализа, а в ночь выступления — прослушивать и отсеивать. Скорость прочёсывания была важнее визуального лоска — никто не станет любоваться анимацией карточки, когда отстаёт от графика в 90-минутном окне подготовки.

Чего они просили снова и снова: видеть BPM, тональность и уровень энергии без наведения курсора и кликов; возможность услышать 30-секундное превью одним касанием; способ найти «все версии этой песни» (чистую, explicit, акапеллу, инструментал, ремиксы); и синхронизацию папок, которая просто работает с тем, как их диджейский софт уже читает файлы. Мы строили под эти четыре потребности, а остальное не трогали.

Полный редизайн интерфейса — что изменилось и почему

Старый интерфейс прятал данные для принятия решений под состояния наведения. Новый их показывает. Мы перешли к плотной строчной раскладке с четырьмя всегда видимыми колонками данных — название и исполнитель, жанр и поджанр, BPM и тональность, и одна кнопка действия, которая раскрывается в скачать / превью / добавить в плейлист. Сетка построена в 12-колоночной системе, поэтому она чисто деградирует до 8 колонок на планшете и складывается в карточную раскладку на мобильном, ничего при этом не теряя.

Навигация переехала из бокового дерева в постоянную верхнюю панель плюс контекстную боковую полосу. Четыре основных раздела: Каталог, Плейлисты, Загрузки, Настройки. Всё остальное стало строиться вокруг поиска, потому что наши данные показали: больше 70% сессий и так начинались с поискового запроса. Фильтры мы пересобрали в виде чипов-пилюль (метка + диапазон BPM + тональность + год + уровень эксклюзивности), чтобы применённые фильтры всегда были читаемы без открытия модального окна.

Старый интерфейс	Новый интерфейс	Эффект
BPM и тональность спрятаны в подсказке при наведении	BPM и тональность показаны прямо в строке, с цветовой кодировкой по колесу Camelot	−47% времени от поиска до скачивания
Боковая панель с 14 пунктами	Верхняя панель, 4 раздела, всё остальное — через поиск	+33% вовлечённости в сессии
Фильтры в модальном окне	Чипы-пилюли прямо на странице	+18% использования фильтров
Превью требовало клика и загрузки аудиоплеера	30-секундное превью одним касанием по строке	+61% прослушанных превью за сессию

Библиотека треков: выносим на поверхность BPM, тональность и источники, которые важны

Каталог охватывает 720 000 лицензированных треков от Sony Music, Universal, Virgin и десятков независимых лейблов. На старой платформе у каждого трека были богатые метаданные — BPM, тональность, жанр, поджанр, год, лейбл, тип микса, окно эксклюзивности, исходные файлы — но интерфейс выводил всё это одним абзацем. Диджеи их пролистывали. Мы реструктурировали панель деталей на три зоны: данные для решения наверху (BPM, тональность, энергия), творческий контекст в середине (лейбл, год, релизный тир) и операционные данные в конце (форматы файлов, история скачиваний, дерево ремиксов).

Дерево ремиксов — это то, что изменилось сильнее всего. На старом сайте клик по «показать все версии» возвращал плоский список. Мы заменили его визуальным деревом: оригинал наверху, чистая и радиоверсии — одна ветка, все ремиксы — соседними узлами с именем ремиксёра и BPM рядом с каждым. Диджеи, пользовавшиеся сайтом годами, говорили нам, что один только этот элемент оправдывал редизайн — они наконец узнавали о существовании ремикса, не разыскивая его специально.

Экосистема SPINS: веб + десктоп + мобайл как одно приложение

До этого проекта FRP существовала только как сайт. Мы построили вокруг него три новых клиента и дали всему набору общее имя продукта — SPINS — чтобы диджеи понимали: они получают один продукт на четырёх поверхностях, а не четыре разрозненных инструмента. Плейлист, который вы создаёте на iPhone, появляется в десктопном приложении за считаные секунды. Трек, скачанный на Windows, уже лежит в папке Serato на вашем Mac, если вы авторизованы на обоих устройствах. Именно эта синхронизация состояния заняла больше всего времени, чтобы заработать как надо.

Все четыре клиента обращаются к одному и тому же GraphQL API и используют общее подмножество одной React-библиотеки компонентов. Дизайн-токены (цвет, шкала шрифтов, отступы) живут в одном репозитории, который импортирует каждый клиент. Когда дизайн-команда меняет правило отступов, веб-приложение, десктопное приложение и оба мобильных подхватывают это при следующей сборке.

Мобильные приложения на React Native — iOS и Android

Мы выбрали React Native, потому что веб-команда FRP уже писала на React, а сроки были жёсткими. Плюс: около 85% кода общие между iOS и Android, одна команда, один набор тестов. Минус: нам пришлось написать два нативных модуля — один для фоновых загрузок, которые переживают сворачивание приложения на iOS, и один для аудиографа, чтобы кроссфейдить превью-клипы без потери кадров из-за потока React.

Мобильный сценарий заточен под прочёсывание: диджей просматривает каталог в дороге, отмечает треки звёздочкой, а десктопное приложение скачивает их автоматически в следующий раз, когда выходит в сеть. Этот паттерн «звезда ставит в очередь на скачивание» стал самой используемой функцией уже после первого месяца. Изначально мы вообще не задумывали скачивание на устройство как основной путь — никто не сводит с телефона, — но мы сделали офлайн-превью, чтобы можно было прослушивать отмеченные треки без сигнала. Посмотрите, как мы формируем команду на React Native рядом с веб- и бэкенд-разработкой, на странице наших услуг по разработке программного обеспечения на заказ.

Десктопное приложение на Electron для Mac OS и Windows

Десктопное приложение — это место, где диджеи делают реальную работу: массовое скачивание, синхронизация папок, перетаскивание в Serato, чат с другими диджеями пула. Мы построили его на Electron с тонким нативным слоем для отслеживания файловой системы и для поведения «свернуть в системный трей», которого диджеи ожидают. Чат работает на той же WebSocket-инфраструктуре, что используют наши клиенты в видеостриминге — добавить его было делом одного дня, как только мы подключили свой готовый стек для стриминга.

Одно контринтуитивное решение: мы намеренно сделали десктопное приложение функционально скромнее веб-приложения. Загрузки, плейлисты, чат, настройки. И всё. Всё, что связано с поиском музыки, происходит в вебе или на мобильном. Логика была такой: диджей в разгар сведения хочет, чтобы десктопное приложение было быстрым, тихим файловым менеджером, а не ещё одним местом, где открывают для себя музыку.

Распознавание музыки — функция «Shazam для ремиксов»

Движок распознавания решает задачу, за которую не берётся ни один потребительский Shazam: он сопоставляет ремиксы, бутлеги и эдиты с их оригиналом. Диджей, услышавший незнакомый бутлег в клубе, может напеть или записать десять секунд на телефон, бросить это в SPINS — и мы вернём каждую ветку ремиксов в каталоге, у которой тот же оригинал, обычно включая чистую версию, explicit-версию, радиоэдит и с полдюжины ремиксов. Потребительское приложение такого не делает.

Под капотом движок использует алгоритм созвездий в стиле Shazam на пиковых частотных опорных точках, но обученный на дереве ремиксов, а не только на оригинале. Каждый отпечаток в индексе несёт ссылку на оригинал и соседние ремиксы, поэтому совпадение возвращает всю семью, а не одну строку. Техническая сборка подробно разобрана в нашем гайде по созданию FRP — а этот материал сосредоточен на том, почему UX ощущался как магия, а не как поиск.

AI-плейлисты по голосу — «итальянский поп, 90-е, 140 BPM»

Вы удерживаете кнопку микрофона, говорите, что хотите, отпускаете. SPINS разбирает произнесённый запрос, превращает его в структурированный запрос по метаданным каталога (жанр, поджанр, эпоха, диапазон BPM, совместимость тональностей), добавляет вектор настроения из признаков, полученных через Essentia, и возвращает стартовый набор из 20 треков, который можно сохранить, перемешать или отредактировать. Весь цикл укладывается меньше чем в четыре секунды при хорошем соединении.

Голосовой ввод мы построили на Whisper от OpenAI (0,45 ₽ за минуту аудио, то есть пренебрежимо мало), а слой «запрос → структура» — на GPT-4o со строгой JSON-схемой. Логика отбора плейлиста — наша собственная: она смешивает кандидатов от LLM с проходом на согласованность по BPM, чтобы каждая соседняя пара треков была в пределах ±3 BPM и совместимой тональности Camelot. Диджеи говорили нам, что именно в этом разница между «интересным плейлистом» и «плейлистом, с которого я реально могу сводить». Если вы хотите добавить такой голосовой слой в свой продукт, начните с наших услуг по интеграции AI.

Чат, синхронизация папок и перетаскивание в Serato

Диджеи попросили три небольшие функции, которые в итоге сдвинули удержание сильнее любого флагманского нововведения. Первая: канал чата внутри десктопного приложения, где диджеи пула могут писать друг другу в личку и делиться внутренними ремиксами пула. Вторая: настраиваемые папки загрузок, которые повторяют структуру, по которой сканируют файлы Serato и rekordbox, — чтобы скачанный трек появлялся в софте диджея без перемещения файла вручную. Третья: перетаскивание из десктопного приложения SPINS прямо в открытое окно Serato, что Electron поддерживает нативно, но что потребовало доработки на Windows.

Именно эти функции сделали переход со старого клиента FRP ощущением «получил инструмент получше», а не «учу новый». В каждом интервью после запуска синхронизацию папок называли по имени.

Архитектура мультиплатформенной системы

Все четыре клиента (веб, десктоп, iOS, Android) общаются с единым GraphQL-шлюзом, который разводит запросы по пяти бэкенд-сервисам: Каталог (нагруженный на чтение, Postgres плюс кэш Redis для частых обращений к «горячим» трекам), Идентификация (Cognito за тонкой обёрткой), Загрузки (очередь задач на базе SQS), Распознавание (сопоставитель отпечатков, Go плюс FAISS) и Плейлисты (пайплайн «голосовой запрос → запрос к каталогу»). Хранилище — S3 для исходного аудио, CloudFront для стриминга превью и отдельный бакет с перекодированными превью, потому что трафик превью в 20 раз больше трафика скачиваний.

Синхронизация состояния между клиентами идёт по WebSocket-каналу на каждого пользователя — когда вы отмечаете трек звёздочкой на мобильном, десктопное приложение получает пуш и подтягивает обновлённый плейлист в течение секунды. Мы сознательно не пытались строить систему на CRDT: для пользователя, чьи четыре клиента почти всегда под его контролем, схема «выигрывает последний записавший» с серверным источником истины вполне годится и на два порядка проще в эксплуатации.

Аудиоотпечатки на масштабе 720 000 треков

В каталоге 720 000 треков, и для каждого снимается отпечаток примерно из 500 пиковых пар-опорных точек (мы подобрали плотность, балансирующую полноту распознавания и размер индекса). Это около 360 миллионов опорных точек в индексе. FAISS IVF-PQ даёт нам поиск ближайших соседей быстрее 100 мс на одной машине c6i.8xlarge; индекс мы шардируем по жанру — в первую очередь ради локальности кэша, а не ради ёмкости.

10-секундный отпечаток-запрос отправляется с клиента в сервис распознавания, сопоставляется с индексом, а затем проходит проверку на временную согласованность: мы доверяем совпадению, только если как минимум 40% пар опорных точек выстраиваются в пространстве временных сдвигов, а не просто совпадают по абсолютному количеству. В этом разница между треком, который действительно делит оригинал, и двумя треками, у которых случайно похожие бочки.

Метрики, которые сдвинулись после запуска

Первые 90 дней после запуска мы отслеживали четыре ключевые метрики и сравнивали их с 90 днями до: время до первого скачивания за сессию, число прослушанных превью за сессию, число активных диджеев в неделю и конверсию в платный тариф.

Метрика	До	После 90 дней	Изменение
Медианное время до первого скачивания	4 мин 12 с	2 мин 14 с	−47%
Превью за сессию	6,8	10,9	+61%
Активные диджеи в неделю	базовый уровень	+22%	+22%
Конверсия пробных периодов в платный тариф	14,3%	19,1%	+34%

Как мы перенесли живую платформу без простоя

FRP ни разу не выключали во время перестройки. Мы шесть недель держали старую и новую версии параллельно, переводя пользователей когортами и сохраняя под обеими общую базу данных, чтобы плейлисты диджея, история скачиваний и сохранённые треки работали в любом клиенте. Когда когорта переходила на новый интерфейс, старый оставался доступен по адресу /legacy ещё две недели — на случай, если кто-то захочет откатиться. После 10-го дня этого не сделал никто.

Единственное, что мы переносили жёстко, — это бэкенд поиска: старый стек на LIKE-запросах был выведен из эксплуатации в первый же день для новой когорты. Откат потребовал бы, чтобы старый интерфейс указывал на поисковый сервис, которого больше не существует. Мы приняли этот риск ради более чистого перехода; альтернативой было держать два поисковых стека в продакшене месяцами.

Пять уроков из улучшения профессионального инструмента для диджеев

Урок 1: плотность информации важнее визуального лоска. Профессиональному диджею, готовящему сет перед выступлением, не нужен просторный, «дышащий» интерфейс. Ему нужны семь параметров в одной просматриваемой строке. Мы потратили две недели на то, чтобы убрать обратно «воздух», который добавили в первом варианте редизайна.

Урок 2: функция, от которой пользователи в восторге, редко оказывается флагманской. Распознавание музыки получило прессу; синхронизация папок получила удержание. Важны обе — но если приходится выбрать одну для инвестиций, выбирайте тихую, которая снимает ежедневное трение.

Урок 3: для мультиплатформенного продукта сначала делите дизайн-токены, потом компоненты. Четыре клиента стали ощущаться как один продукт во многом потому, что цвет, шрифты и отступы приходили из одного места. На деле общими являются лишь 30% компонентов.

Урок 4: внедряйте AI как помощника в рабочем процессе, а не как замену. Функция голосовых плейлистов популярна, потому что экономит десять минут ручной фильтрации, а затем отдаёт диджею плейлист, который он всё ещё может отредактировать. Если бы мы попытались сразу проигрывать сгенерированный сет, диджеи перестали бы доверять функции в течение недели.

Урок 5: держите старое и новое параллельно дольше, чем кажется необходимым. Мы оставляли старый клиент работающим две недели после миграции каждой когорты. Это почти ничего не стоило в эксплуатации и принесло нам огромную лояльность опытных пользователей, которые нервничали из-за перестройки.

Стоимость создания похожей экосистемы в 2026 году

Примерные диапазоны по порядку величины для продукта с уже существующим каталогом и клиентской базой, модернизированного так, как мы модернизировали FRP. Они исходят из того, что у вас уже есть лицензирование, хранилище, метаданные каталога и работающий бэкенд — стоимость здесь складывается из перестройки UX, нативных клиентов и двух AI-функций.

Направление работ	Длительность	Команда	Ориентировочно
UX-исследование + редизайн + перестройка веба	10 недель	2 дизайнера, 3 фронтендера	9–12 млн ₽
React Native iOS + Android	12 недель	2 мобильных разработчика, общий бэкенд	8,2–11 млн ₽
Десктоп на Electron (Mac + Windows)	8 недель	1 senior-разработчик + общий фронтенд	4,1–5,6 млн ₽
Движок распознавания (отпечатки + сопоставитель)	10 недель	1 ML-инженер, 1 бэкендер	6–8,2 млн ₽
AI-функция голосовых плейлистов	4 недели	1 бэкендер + общий фронтенд	1,8–3 млн ₽
Накладные на PM + QA + DevOps	на всём протяжении	1 менеджер проекта, 1 QA, общий DevOps	5,2–7,5 млн ₽

Итого ориентировочно: 34,5–47 млн ₽ примерно за шесть календарных месяцев при условии, что направления работ идут параллельно там, где это позволяют зависимости. Мы стоим дешевле большинства американских и западноевропейских агентств сопоставимого качества, потому что наша senior-команда базируется в Восточной Европе и ОАЭ. Актуальные диапазоны можно посмотреть на странице наших услуг по разработке программного обеспечения на заказ.

Когда нанимать Фора Софт, а когда строить своими силами

Нанимайте Фора Софт, когда у вас есть живой продукт с реальными пользователями, вы хотите модернизировать его, не останавливая дорожную карту, и у вас нет полноценной команды нативной мобильной разработки + аудиостриминга внутри. Мы выпустили шесть музыкальных и аудиопродуктов сопоставимой сложности и можем подключиться в течение трёх недель.

Стройте своими силами, когда у вас уже есть глубина в предметной области — мобильный лид, который выпустил приложение на React Native, DSP-инженер для стороны распознавания и собственная дизайн-система, которой вы доверяете, — и модернизация достаточно мала, чтобы подключение агентства обошлось дороже, чем сэкономит.

Частые вопросы

Чем эта статья отличается от вашего гайда по созданию FRP?

Гайд по созданию отвечает на вопрос «как бы я построил диджейский пул с нуля?» — архитектура, лицензирование, стоимость. Эта статья отвечает на вопрос «как бы я модернизировал существующий, не потеряв пользователей?» — редизайн UX, добавление нативных клиентов, навешивание распознавания и AI.

Может ли движок распознавания работать с записями из шумного клуба?

Да, примерно до 10 дБ отношения сигнал/шум, прежде чем точность начнёт заметно падать. Алгоритм созвездий сопоставляет по пиковым частотам, которые переживают шум толпы лучше, чем полноспектральные методы.

Почему React Native и Electron, а не полностью нативная разработка?

Время выхода на рынок и эффект масштаба команды. Фронтенд-команда была React-цехом. Мы добрались до четырёх платформ тремя небольшими командами вместо шести. Там, где нас кусал JS-мост — фоновые загрузки, аудиограф, — мы уходили в нативные модули.

Сколько времени занимает запрос AI-плейлиста от начала до конца?

Обычно 3–4 секунды при хорошем соединении. Бо́льшая часть времени уходит на транскрипцию Whisper и вызов GPT-4o; сам запрос к каталогу возвращается быстрее 100 мс.

Просили ли какие-нибудь диджеи откатиться назад?

Ни одного после 10-го дня каждой когорты. В дни 1–5 была горстка запросов на откат, почти все — про горячие клавиши, которые мы изменили. Мы добавили настройку сочетаний клавиш в первом спринте после запуска, и запросы на откат прекратились.

Как вы справляетесь с DMCA и несанкционированными загрузками через функцию распознавания?

Функция распознавания сопоставляет только с лицензированным каталогом. Она не принимает сторонние загрузки и не хранит присланное пользователем аудио сверх короткого клипа-запроса, который удаляется после сопоставления. Это обходит почти любую проблему с DMCA, с которой столкнулся бы потребительский клон Shazam.

Стали бы вы использовать тот же стек сегодня, в 2026 году?

В основном да. На проектах с нуля мы бы поменяли Electron на Tauri (меньше бинарник, меньше памяти) и попробовали бы Vercel AI SDK для разбора голосового запроса. Архитектуру отпечатков и каталога мы по-прежнему выбрали бы такой же.

Вы работаете с небольшими музыкальными стартапами или только с устоявшимися каталогами вроде FRP?

И с теми, и с другими. Для аудиостартапов на ранней стадии мы обычно объединяем UX и инженерию MVP в 12-недельную разработку. Список проектов по всему спектру есть на странице наших музыкальных услуг.

Что почитать дальше

Готовы модернизировать свой аудиопродукт?

Фора Софт перестроила FRP в экосистему SPINS из четырёх продуктов с распознаванием в духе Shazam и AI-плейлистами по голосу — и сдвинула платную конверсию на 34% без единого дня простоя. Если у вас есть живой аудиопродукт, которому нужен похожий апдейт, мы проведём исследование, пришлём фиксированную оценку в течение двух рабочих дней и стартуем в течение трёх недель.