Месяц собирал КВН-сервис с ИИ. Технически получилось, клиентов пока 0

Для себя КВН можно поднять довольно быстро: купить виртуальный сервер, поставить Xray, получить ключ, добавить его в приложение и пользоваться. Сервис для других людей оказался совсем другой задачей.

Я не разработчик по профессии. Небольшие технические знания есть, но код для меня не родная среда, и в большинстве деталей я разбирался уже по дороге. Поэтому проект почти целиком делался с помощью ИИ: я ставил задачи, проверял результат, запускал, ловил ошибки и возвращал их обратно в работу.

За основной спринт получилось собрать рабочий Telegram-сценарий вокруг ключей: бота, оплату, админку, поддержку, несколько серверов и первые попытки маркетинга. По истории коммитов это 463 изменения примерно за месяц. Клиентов на старте — 0.

Это не инструкция по настройке доступа и не реклама сервиса. Это история о том, как простой на вид КВН-бот постепенно превратился в сервис с оплатой, серверами, поддержкой, бэкапами, маркетингом и неожиданными проблемами по дороге.

Когда делаешь КВН для себя, цена ошибки небольшая: если что-то сломалось, разбираешься сам и никому ничего не должен. С пользователем так не работает: он оплатил доступ и ждёт результат. Значит, сервис должен понимать, на каком этапе всё находится: оплата прошла, ключ создаётся, ключ выдан или что-то сломалось.

Из этого выросла первая важная часть сервиса: отдельные состояния для оплаты и выдачи ключа. Условно:

- пользователь начал оплату;
- оплата прошла;
- система создаёт ключ;
- ключ выдан;
- если что-то временно сломалось, задача повторяется;
- если сломалось окончательно, админ видит проблему.

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

Изначально я думал о довольно простом Telegram-сценарии:

1. человек открывает бота;
2. выбирает тариф;
3. оплачивает;
4. получает ссылку и QR-код;
5. потом сам продлевает подписку.

На бумаге это выглядит короткой цепочкой.

Вокруг неё быстро выросла инфраструктура: база для пользователей и подписок, платежи, Marzban для выдачи ключей, админка, мониторинг серверов и бэкапы.

Отдельно появились ограничения: сколько устройств можно использовать, какая скорость у тарифа, на какой сервер выдать пользователя, как понять, что сервер перегружен, когда не продавать новый доступ, потому что мощности уже мало.

Самые интересные сложности начались там, где обычная логика сервиса встретилась с сетевой частью.

Например, лимит устройств. В тарифе можно написать "до 4 устройств", но сервер не присылает красивый список: телефон, ноутбук, планшет. Он пишет технический журнал подключений. Из него надо понять, сколько разных клиентов реально использует один ключ, где нормальное поведение, а где явное превышение.

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

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

С несколькими серверами история стала ещё сложнее. Нужно правильно подключить сервер к панели, выдать сертификаты, проверить, что он действительно живой, и только потом отправлять туда пользователей.

Самый показательный случай был с Marzban.

Мне нужно было включить документацию API. На вид мелочь: поменять настройку и перезапустить контейнер. После перезапуска часть конфигурации панели пропала, и выданные подписки стали пустыми. Пришлось восстанавливать из бэкапа.

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

Параллельно пришлось собирать не только код, но и упаковку продукта. Сначала — базовые вещи: название, позиционирование, тарифы и ограничения. Потом всё, что видит пользователь: тексты в боте, канал, первый пост, маскот.

Хотелось, чтобы это выглядело как небольшой живой проект.

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

Также я заморочился и отдельно сделал стикеры.

Потом началась проверка привлечения. Первая идея была простая - холодная рассылка через Telegram. Исход неудивительный - блокировки, недовольные ответы и игнор. Подход пришлось менять: меньше продажи, больше исследовательского вопроса, без быстрых ссылок и обещаний. Вместо того, чтобы предлагать сервис, я спрашивал, чем человек пользуется, но результата это не дало, и от данного метода я отказался.

Была попытка через Telegram Ads, но из-за ограничений платформы нормально показать рекламу пользователям из РФ не получилось, поэтому я попробовал обходной вариант: русскоязычную аудиторию в ОАЭ. Там КВН тоже нужен для звонков через мессенджеры. Тест дал 1 766 показов, 3 клика, 1 действие и 0 клиентов. Конверсия в покупку — нулевая. Ещё один следующий канал, который я хотел проверить — короткие видео, но до нормального теста пока не дошёл.

В плотный период с середины апреля по середину мая получилось 463 коммита. Чаще всего возвращались такие темы:

- маркетинг и проверка привлечения;
- серверы и ноды;
- поддержка пользователей;
- Marzban и выдача ключей;
- автоматизация настройки серверов;
- лимиты скорости и устройств;
- мониторинг и бэкапы.

К концу месяца стало понятно, что технически сервис можно довести довольно далеко: медленно, через ошибки, с помощью ИИ и большим количеством проверок.

Но к этому моменту у меня всё ещё не было главного — понятного пути к первым покупателям. Не было аудитории до запуска. Не было сильного канала. Не было узкой группы людей, для которой сервис выглядел бы как решение именно их проблемы.

КВН — конкурентная ниша. Для пользователя это не место, где он хочет изучать архитектуру. Ему важно, чтобы работало, было понятно, безопасно по ощущениям и чтобы сервису можно было доверять. У неизвестного проекта такого доверия нет по умолчанию.

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

Если интересно посмотреть, что в итоге получилось, можно написать мне в Telegram: @shapovpv .