Ошибались, спотыкались, спорили — и всё же довели до релиза деловой «Тиндер» без прокачанного фронтенда, без дорогой инфраструктуры и без опыта большой командной разработки. Ни запуск стартапа, ни поиск инвестиций не были нашей целью: нам банально не хватало среды, где можно быстро находить «своих» — людей с похожими интересами, навыками и мотивацией для совместных проектов. Поэтому мы, студенты ФИИТ (УрФУ) под кураторством Контура, взялись за мини‑приложение в Telegram, в котором знакомиться по делу так же легко, как лайкать анкеты.
За три семестра — примерно девять месяцев — мы прошли путь от эскизного прототипа до рабочей версии. Начали с пользовательского сценария: вход в приложение, заполнение профиля, выбор интересов, получение регулярных рекомендаций и взаимные «лайки», после которых открывается чат в мессенджере. Обычные соцсети для такой задачи не годятся: алгоритмы рекомендаций там заточены под удержание, а не под точные совпадения по профессиональным критериям.
Бэкенд мы написали на Python, объединив Django и FastAPI. От Django взяли зрелую ORM с миграциями и админку «из коробки» — это сильно ускорило первые итерации. FastAPI добавил нам автодокументацию и строгую валидацию входящих запросов, а также удобную работу с асинхронщиной. Да, сочетание нетривиальное: практически на каждом ревью нас спрашивали, зачем мы совмещаем «два царства», если «обычно» выбирают одно. Мы сознательно пошли на это, чтобы использовать сильные стороны обоих фреймворков и не ждать, пока разовьёмся до идеального рефакторинга.
Хранили данные в PostgreSQL, медиафайлы вынесли в S3‑совместимое облачное хранилище. Фронтенд реализовали на TypeScript с React и Redux — хотя изначально фронтендерских навыков у нас не было. Разобрали основы, подняли каркас, настроили состояние. Интерфейс — это Telegram Mini App: браузерный клиент живёт внутри мессенджера, но архитектурно остаётся обычным SPA на React. Запросы маршрутизируются через Nginx. Инфраструктуру развернули в Yandex Cloud, а сборку, тесты и деплой автоматизировали через GitHub Actions: пуш — и пайплайн сам катит изменения на окружения.
Почему именно такой стек? На всё есть документация, много примеров и активные площадки обмена знаниями; у каждого из нас был хотя бы минимальный опыт с частью инструментов, а остальное добрали в бою. Плюс высокая скорость разработки: с этим набором технологий можно быстро валидировать гипотезы и чинить промахи.
Мы работали короткими двухнедельными спринтами, созванивались по выходным и в конце каждого спринта проводили ретроспективу. Такой ритм помогал преподавателям отслеживать прогресс, а нам — не утонуть в нагрузке на фоне учёбы. На регулярных синках распределяли задачи и старались выровнять загрузку. Для планирования использовали Buildin.ai — аналог знакомых бордов с задачами. Главная боль — оценки. Казалось, что задача на бэкенде тянет на «S», но если её берёт человек послабее основного бэкендера, объём неожиданно раздувается. Мы научились закладывать буфер на неопределённость и дробить крупные куски на атомарные шаги.
Как работает сопоставление анкет. Мы избегали «магии» и начали с простого скоринга по тегам: навыки, интересы, роли и ожидаемая вовлечённость. У каждого атрибута вес, итог — нормализованный рейтинг кандидатов. Чтобы снизить эффект «эхо‑камеры», в выдачу добавляется доля «исследовательских» рекомендаций — профили с частичным совпадением, но потенциально интересные. Для «холодного старта» новые пользователи временно повышаются в выдаче, чтобы быстрее получить первые сигналы.
Антиспам и модерация. Мы сразу заложили жалобы на профиль и сообщения, простую эвристику на подозрительную активность (слишком много лайков за короткий промежуток) и soft‑бан по уровням. В чате по умолчанию скрываем внешние контакты до взаимного согласия — так меньше соблазна рассыпать спам‑ссылки. В планах — автоматическая модерация медиаконтента и текстов на базе облачных моделей классификации.
Про приватность и безопасность. Все пароли и токены лежат в секретах окружения, доступы ограничены по ролям, в базе включён аудит критичных операций. Файлы — с временными ссылками доступа. Для пользовательских данных ввели политику минимальной необходимой информации: то, что не помогает подбору, не собираем.
Тестирование и качество. На бэкенде — юнит‑тесты для сервисов и репозиториев, компонентные тесты эндпойнтов и smoke‑набор для пайплайна. На фронте — тесты критических редьюсеров и простые e2e‑сценарии авторизации, создания профиля и лайка/матча. Линтеры и форматтеры обязательны в pre‑commit, code review — с чек‑листом. Это спасло от множества «тихих» регрессий.
Наблюдаемость и стоимость. Логи собираем централизованно, метрики сервера и БД мониторим, на SLA‑критичные метрики поставили алерты. Чтобы не улетать в расходы, выключаем стейджинги на ночь, используем авто‑скейлинг по минимуму, кэшируем тяжёлые запросы и чистим S3 от «мусорных» медиа. Это дало ощутимую экономию без потери удобства.
Грабли с фронтендом. Отсутствие опыта вылезло в виде «магического» состояния и гонок при обновлении стора. Мы переписали критичные места на более явные эффекты, ввели правило: любые асинхронные операции — только через слой сервисов с единым контрактом, а не «внутри компонента по настроению». Параллельно навели типизацию: строгие типы для API‑моделей и мапперы между доменной и сетевой схемой.
Командные процессы и софты. Мы не только делили задачи, но и учились отдавать «скучные» куски — документацию, миграции, тесты — по кругу, чтобы не возникло «узких мест». На ретро фиксировали не только технические итоги, но и настроение: если кто‑то выгорел на рутине, в следующем спринте он брал что‑то более творческое. Это простое правило поддержало темп и не дало нам скатиться в хаос.
Что получилось в итоге. Рабочая версия мини‑приложения в Telegram с профилями, тегами, выдачей рекомендаций, взаимными лайками и чатами. Админка для модерации, система жалоб, базовая аналитика по вовлечённости. CI/CD, инфраструктура в облаке, документация для разработчиков и онбординг. Мы закрыли основной пользовательский сценарий и создали основу для роста.
Планы на развитие.
- Улучшить подбор через гибридную модель: теги + поведенческие сигналы, постепенно перейти к более «умному» ранжированию.
- Добавить групповые матчи для тех, кто ищет сразу команду.
- Сделать умные подсказки для профиля, чтобы повысить качество рекомендаций и конверсии в матч.
- Расширить антиспам и ввести автоматическую модерацию медиа.
- Развернуть канареечные релизы и фичефлаги, чтобы безопасно проверять гипотезы.
- Оптимизировать рендеры фронта и перевести часть тяжёлых виджетов на виртуализацию списков.
Главный урок — скорость не равна спешке. Быстро выбирать стек хорошо, но ещё лучше заранее договориться об архитектурных принципах, критериях качества и правилах взаимодействия. Мы убедились, что без огромного бюджета и десятка сеньоров можно собрать работающий сервис: если дробить цели, внимательно относиться к процессам, не бояться менять решения и вовремя признавать ошибки. И да — даже без стартового знания фронтенда можно построить интерфейс, который не мешает продукту, а помогает ему расти.
