Dating Bot: как Telegram стал MVP для дейтинга
В этом проекте сначала не было кода. Были брендбук, несколько экранов от дизайнера и ощущение, что идея хорошая, но до полноценного приложения ей ещё далеко.
Друг показал мне материалы и попросил просто посмотреть со стороны. У него был партнёр, у партнёра — юридическое лицо и желание делать дейтинг. Денег на полноценные iOS и Android не хватало. Технического задания тоже не было. Было только направление: нужно проверить гипотезу и показать, что продукт может жить.
Я довольно быстро предложил Telegram-бота.
Не потому что бот — это дешёвая замена приложению. Такой подход обычно заканчивается кривым MVP, который стыдно показывать. Я смотрел на Telegram иначе: как на быстрый вход в продукт, где аудитории не нужно скачивать ещё одно приложение, проходить длинную регистрацию и привыкать к новому интерфейсу.
MVP, который не выбрасывается
Главная ошибка многих MVP — их делают как времянку. Быстро собрали, кое-как проверили, потом всё переписали с нуля.
Мне хотелось другого. Telegram должен был стать первым интерфейсом к нормальному бэкенду, а не отдельной игрушкой. Если гипотеза сработает, серверная логика останется: анкеты, лайки, матчи, сообщения, платежи, модерация. Потом можно добавить мобильное приложение или расширить Mini App, не выбрасывая основу.
Поэтому я сразу думал не только о кнопках в боте, а о системе: где живут данные, как устроены состояния пользователя, как отделить Telegram-слой от бизнес-логики, как потом не упереться в собственную архитектуру.
Здесь хорошо сочетаются Django и aiogram. Django даёт базу, модели, миграции, админку и API. aiogram отвечает за Telegram-часть: команды, состояния, сообщения, кнопки. Бот не должен напрямую превращаться в базу данных на коленке. Он должен быть интерфейсом.
Telegram оказался не компромиссом
У дейтинга есть неприятная особенность: пользователь устал ещё до того, как начал. Нужно скачать приложение, создать профиль, выбрать фото, заполнить анкету, привыкнуть к ленте. Каждый шаг съедает часть людей.
Telegram снимает часть этого трения. Пользователь уже там. Он понимает, как писать, как получать уведомления, как открыть чат. Поэтому бот даёт продукту шанс быстрее попасть в привычную среду человека.
Об этом я отдельно писал в статье Знакомства в Telegram: ближе, чем приложение. Там мысль проще: если всё равно после матча люди уходят в мессенджер, странно игнорировать мессенджер как стартовую площадку.
Но у Telegram есть и ограничения. Кнопки быстро становятся тесными. Лента профилей, сторис, чат, настройки — всё это неудобно держать только в сообщениях. Поэтому я сразу держал в голове Mini App: бот для входа, уведомлений и простых действий; веб-интерфейс внутри Telegram — для плотного продукта.
Самая сложная часть была не в лайках
Снаружи кажется, что дейтинг — это анкета, лайк, матч, чат. На деле технически острые места начинаются глубже.
Первое — онбординг. Пользователь может прислать не то фото, пропустить шаг, написать возраст текстом, уйти на середине, вернуться через день. FSM в aiogram помогает удерживать состояние, но сам сценарий всё равно нужно проектировать аккуратно. Бот должен вести человека, а не спорить с ним.
Второе — чат. Telegram-бот не даёт двум людям просто так писать друг другу напрямую. Всё идёт через посредника. Нужно хранить связь между участниками, пересылать текст и медиа, не раскрывать аккаунты, не ломать анонимность. Это уже не кнопка “написать”, а полноценная система доставки сообщений.
Третье — модерация. В дейтинге фотографии и тексты нельзя оставлять без контроля. Ручная проверка быстро перестаёт масштабироваться, поэтому появился ML-пайплайн: загрузка, очередь, проверка, решение, иногда ручная перепроверка. Не потому что хотелось добавить модное AI-слово, а потому что без автоматизации такой продукт превращается в бесконечную ручную вахту.
Эта часть дала мне много понимания, которое потом пригодилось в RuVn Mod: реальные пользователи редко ведут себя так аккуратно, как ты нарисовал в сценарии.
37 миграций — нормальная биография живого продукта
База данных менялась постоянно. Появлялись блокировки, история просмотров, новые поля профиля, платные действия, статусы модерации, сообщения, платежи, сторис. В итоге набралось 37 миграций.
Это число звучит как признак хаоса, но для MVP оно скорее честное. Ты не знаешь предметную область идеально в первый день. Ты узнаёшь её через пользователей, через странные кейсы, через то, что “очевидная” схема внезапно не покрывает реальное поведение.
Важный урок: миграции не страшны, если система развивается осознанно. Страшно, когда данные начинают жить без правил, а каждое новое поле добавляется с мыслью “потом разберёмся”. Потом обычно становится дороже.
Django здесь сильно помог. Админка дала быстрый контроль над пользователями и модерацией. ORM позволил менять модель без ручного SQL на каждом шаге. DRF стал понятной прослойкой между ботом, Mini App и серверной логикой.
Деньги, сообщения и доверие
Монетизация в дейтинге тонкая. Если поставить платный забор слишком рано, продукт выглядит жадным. Если всё открыть бесплатно, неясно, как поддерживать инфраструктуру.
Мы пошли через внутренний баланс и точечные платные действия: расширенные сообщения, бусты, донаты. Платёжный слой завязали на YooKassa и Telegram Payments. С точки зрения пользователя это должно ощущаться просто: нажал, оплатил, получил действие. Внутри же нужны транзакции, проверки, callback-и, история операций и защита от несостыковок.
Параллельно оставался вопрос доверия. Дейтинг-продукт работает только тогда, когда человек чувствует контроль: над профилем, перепиской, приватностью, оплатой, тем, кто видит его данные. Поэтому безопасность и анонимность здесь не “техническая деталь”, а часть продукта.
Про усталость от классических дейтинг-приложений я отдельно писал в статье Почему дейтинг-приложения утомляют. Dating Bot для меня был попыткой сделать формат спокойнее: меньше бесконечного свайпа, больше понятного общения.
Что я вынес из проекта
Dating Bot начался как просьба посмотреть на идею. В итоге получился Django-бэкенд, aiogram-бот, Mini App на React, WebSocket-чат, ML-модерация, платежи и нормальная архитектура для роста.
Главный вывод простой: Telegram-бот может быть не временной поделкой, а первым интерфейсом серьёзного продукта. Но только если относиться к нему как к продукту с архитектурой, а не как к набору команд.
Мне понравился этот проект именно тем, что он не дал спрятаться за простые ответы. Дейтинг кажется лёгким, пока не начинаешь делать его по-настоящему. А потом выясняется, что там есть всё: психология, безопасность, платежи, real-time, модерация, UX и очень много неожиданных человеческих сценариев.