Бот отлично справляется, пока сценарий укладывается в диалог. Ответить на вопрос, принять заявку, прислать статус заказа — это переписка, и переписки для неё достаточно.
Проблема начинается там, где в сценарии появляется выбор. Тариф с параметрами, каталог из тридцати позиций, форма из шести полей, конструктор, где один пункт зависит от другого. Всё это можно впихнуть в кнопки и текстовые сообщения, но получится интерфейс из 2010 года — пользователь листает шаги вперёд-назад, путается, бросает на середине. Именно здесь бот перестаёт справляться и в игру входит Mini App.
Что это технически
Mini App в MAX — веб-приложение, которое живёт внутри мессенджера и открывается по кнопке от бота. Технологии под капотом обычные: HTML, CSS, JS, любой фреймворк, который умеет собираться в статику. Мы делаем фронт на React и Next.js — ничего специфичного MAX не требует, это такая же сборка, как для обычного сайта, просто с другой точкой входа.
Схема запуска простая: приложение собирается, выкладывается на хостинг с https, а его URL привязывается к боту через партнёрскую панель. С сервера MAX отдаёт мост — MAX Bridge, — через который приложение общается с платформой: получает данные пользователя, вызывает нативные элементы интерфейса, обменивается событиями с ботом.
Важный момент, который упускают в половине статей на эту тему: хостинг должен быть быстрым и стабильным. Мини-приложение открывается в мессенджере, у пользователя нет терпения ждать пять секунд первую отрисовку — он просто закроет вкладку и вернётся к переписке с ботом. Бесплатный статический хостинг с холодным стартом здесь не подходит; мы разворачиваем на своих серверах именно поэтому.
Где Mini App реально нужен
Не везде, где можно, — нужно.
Конструктор с параметрами. Тариф, где пользователь выбирает срок, объём, набор опций, и всё это меняет итоговую цену в реальном времени. В переписке с ботом это пять сообщений подряд и постоянное «а можно вернуться на шаг назад». В интерфейсе — один экран со слайдерами и переключателями, и цена сразу видна.
Каталог. Больше десяти позиций с фильтрами, категориями, поиском — это уже не список кнопок, а витрина. Здесь работают карточки, сетка, сортировка — всё, что переписка физически не может показать.
Личный кабинет. История заказов, статус подписки, настройки, реферальная программа — данные, которые пользователь хочет видеть целиком, а не выуживать командами по одному пункту.
Оплата с деталями. Если это просто «оплатить 500 рублей» — хватит кнопки оплаты в чате. Если нужно выбрать способ, ввести промокод, посмотреть разбивку — это уже форма, а форма живёт в интерфейсе, не в диалоге.
Игровые механики — розыгрыши, колесо призов, накопительные баллы — тоже почти всегда уезжают в Mini App: анимация и интерактив в переписке не работают в принципе, а в вебе это несколько дней вёрстки.
Где Mini App не нужен, а бота достаточно
Отдельно скажем, потому что нам самим приходится отговаривать клиентов от лишней разработки.
Если весь сценарий — это «ответить на вопрос» или «принять один параметр и подтвердить», мини-приложение — избыточная трата бюджета. FAQ-бот, запись на процедуру в одну услугу, приём заявки с тремя полями — всё это закрывается диалогом за меньшие деньги и без отдельного фронтенда, который потом надо поддерживать.
Хорошее правило: если можно нарисовать сценарий как блок-схему с развилками из двух-трёх вариантов на каждом шаге — хватит бота. Если развилок больше или нужен визуальный выбор из множества опций одновременно — пора в интерфейс.
Как выглядит хороший Mini App в MAX
Тут вступает не техническая часть, а дизайнерская, и это ровно то, где чаще всего экономят зря.
Мини-приложение открывается внутри мессенджера, и пользователь ждёт, что оно будет выглядеть как нативная часть платформы — не как встроенный сайт с чужим шрифтом и не тем радиусом скругления. На практике это значит: карточки с крупным радиусом, компактные тач-таргеты под палец, а не под курсор, предсказуемая навигация без глубокой вложенности экранов, и таб-бар или кнопка «назад», которые ведут себя так же, как в остальном мессенджере.
Когда мы проектируем такие интерфейсы — будь то конструктор тарифа с выбором параметров и живым пересчётом цены, каталог с покупкой без лишней авторизации, или личный кабинет с историей и рефералкой — правило одно: сначала мобильный экран, потом уже растягивание под десктоп, если он вообще нужен. Мини-приложение в 95% случаев открывают с телефона, и дизайн, сделанный «для широкого экрана, а потом сожмём», в мессенджере обычно выглядит тесным и нелогичным.
Ограничения, о которых стоит знать заранее
MAX следит, чтобы мини-приложение не вводило пользователя в заблуждение относительно того, что оно делает — то же требование, что и к ботам. Название, иконка и первый экран должны соответствовать реальной функции.
Разработка Mini App обычно обходится дешевле отдельного мобильного приложения — не в разы, но заметно, потому что не нужны нативные iOS/Android-сборки, публикация в сторах и их отдельная поддержка. Но это не значит «дёшево вообще» — дизайн интерфейса с несколькими экранами и логикой всё равно требует времени, сопоставимого с небольшим лендингом, только с бо́льшим вниманием к интерактивным состояниям: что происходит при загрузке, при ошибке, при пустом списке.
Сроки
Простой Mini App на 3–4 экрана без сложной логики — полторы-две недели вместе с дизайном и вёрсткой. Конструктор с несколькими зависимыми параметрами, личный кабинет с историей и рефералкой — от трёх недель, и это без гарантии, что ТЗ не разрастётся в процессе: у таких интерфейсов почти всегда находится «а давайте ещё добавим экран с...» уже после старта.
Закладывайте отдельно неделю на тестирование на реальных устройствах — верстка мини-приложений капризна к разным версиям MAX и разным экранам, и то, что красиво выглядит в дизайне, иногда едет на конкретном телефоне.
Проектируем мини-приложения под MAX и Telegram — от конструктора тарифа до личного кабинета с рефералкой. Если сомневаетесь, нужен вам бот или полноценный интерфейс, — напишите, посмотрим на сценарий вместе.
