Telegram mini app без разработчика: 50 тысяч строк и реальные платежи

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

Два участника клуба прошли этот путь на разных проектах и получили разный результат. Разница между ними оказалась не в инструменте.

Задача выросла по дороге

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

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

Что в итоге работает

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

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

Где всё-таки понадобился человек

Полностью автономным проект не был, и это важная часть картины.

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

А вот дизайнера на проекте действительно не было. За интерфейс отвечал отдельный навык для фронтенда, и именно он вытянул приложение из состояния «работает, но смотреть больно», из-за которого у вайбкодинга репутация инструмента для уродливых прототипов.

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

Почему «ничего не упало» стоит читать осторожно

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

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

Процесс, который появился после первых багов

Там было мобильное приложение, кроссплатформенная сборка и заказчик с командой, которая три месяца не могла дойти до релиза. Когда сборка стала достаточно стабильной, её отдали тестировщику. Тестировщик вернул баги.

Первые попытки чинить закончились предсказуемо. Агент писал тест, писал код, тест проходил — а ошибка оставалась на месте. Разбор показал, в чём дело: агент чинил то, что понял из описания, ни разу не увидев ошибку своими глазами.

Выход нашёлся в жёсткой последовательности, где код появляется последним:

1. Описать человеческим языком сценарий, при котором ошибка воспроизводится.
2. Превратить его в тест-кейс, который агент прогонит сам на эмуляторе.
3. Написать тесты, которые на этом этапе обязаны упасть.
4. Изучить контракты вместо самого кода: набор параметров и что возвращает метод.
5. Только теперь писать код, который чинит ошибку и проходит тесты.
6. Прогнать всё и свериться с отдельным файлом: какие сценарии покрыты, какие нет.

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

Плохое ТЗ ломает больше, чем плохой код

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

Внутри он был противоречив. Цена подписки называлась в трёх местах, и все три раза разная. В одном разделе фигурировало два тарифа, в другом три. Часть сценариев отсутствовала вовсе. Отдать такое агенту означало получить приложение, собранное по трём несовместимым описаниям сразу.

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

Что из этого следует

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

Разница между проектами не в модели и не в инструменте. В одном случае никто не искал ошибки, в другом искали — и там, где искали, пришлось выстраивать порядок, при котором агент сначала воспроизводит проблему и только потом её чинит.

Это приложение было одним из пяти проектов, которые автор собрал за тот период, и порядок с воспроизведением ошибки родился именно здесь — на остальных он уже применялся с самого начала.