Разработка мини-приложения для MAX: от прототипа до публикации

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

Этапы проекта коротко

Если вы пока выясняете, что такое мини-приложение и нужно ли оно вам, начните со статьи «Мини-приложения в MAX: что это и кому они нужны». Здесь — о том, как его делают.

Этапы частично идут параллельно: пока дизайнер дорабатывает экраны, бэкенд-разработчик уже проектирует API. Но прототип всегда первый — без него все остальные оценки гадание.

Прототип и UX

На этом этапе отвечаем на три вопроса: кто пользователь, какое одно действие он должен совершить и что мешает ему сделать это сейчас. Например, для автосервиса это «записаться на шиномонтаж на ближайшее свободное время», а не «познакомиться с компанией».

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

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

Особенности интерфейса внутри мессенджера, которые стоит учесть сразу:

• Экран узкий, а у мессенджера есть свои элементы управления — шапка, кнопка закрытия. Важные кнопки не должны под них попадать.
• Пользователь держит телефон одной рукой, поэтому главное действие лучше размещать внизу, в зоне большого пальца.
• Светлая и тёмная тема: передаёт ли платформа параметры оформления и как их получить, уточняется по документации.
• Как работает кнопка «назад» и как закрывается приложение — тоже по документации, чтобы пользователь не потерял введённые данные.

Фронтенд

Мини-приложение — это веб-приложение, поэтому стек привычный: React, Vue или лёгкий фреймворк, если экранов немного. Мы обычно выбираем то, с чем потом будет удобно работать команде заказчика, а не самое модное.

Главное техническое требование — скорость. Человек нажал кнопку в чате и ждёт; если белый экран висит несколько секунд, он закроет окно. Поэтому следим за размером сборки, грузим изображения постепенно, показываем каркас интерфейса до прихода данных.

Связь с мессенджером идёт через инструменты, которые платформа предоставляет веб-приложениям: получение данных запуска, взаимодействие с интерфейсом MAX, закрытие окна. Как их подключить и что именно доступно, описано в документации на dev.max.ru. Код, который работает с платформой, мы держим в отдельном модуле — если позже понадобится версия для Telegram, менять придётся только его.

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

Бэкенд и интеграции

Фронтенд показывает экраны, а всё важное происходит на сервере: расчёт цен, проверка свободных слотов, сохранение заказов, обмен с CRM и учётной системой. Логику, от которой зависят деньги и данные, нельзя оставлять в браузере — её легко подменить.

Обычно бэкенд мини-приложения — тот же сервер, что обслуживает бота. Это удобно: заказ, оформленный в приложении, бот тут же подтверждает сообщением в чате, а дальше присылает статусы. Если нужно передавать заказы в amoCRM, Битрикс24 или 1С, подробности — в статье об интеграции с CRM.

• REST или GraphQL API для фронтенда.
• База данных: пользователи, заказы, записи, справочники.
• Очередь задач для медленных операций — выгрузки в CRM, отправки уведомлений.
• Админ-панель для сотрудников: заказы, статусы, контент приложения.

Отдельно закладываем базовую защиту: ограничение частоты запросов к API, логирование ошибок с уведомлениями разработчику, резервные копии базы. Если приложение собирает телефоны и имена, учитываются требования 152-ФЗ — согласие на обработку, место хранения данных и доступы сотрудников.

Как приложение узнаёт пользователя

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

Правильная схема такая:

1. Фронтенд получает от платформы данные запуска и отправляет их на сервер целиком, без изменений.
2. Сервер проверяет подлинность этих данных по алгоритму, который описан в документации MAX, и их свежесть.
3. Только после успешной проверки сервер находит или создаёт пользователя и выдаёт свой токен сессии.
4. Все дальнейшие запросы фронтенд делает с этим токеном.

Оплата

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

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

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

Тестирование и публикация

1. Проверка на нескольких телефонах с iOS и Android и в десктопной версии мессенджера, если приложение там должно работать.
2. Медленный мобильный интернет: приложение должно оставаться понятным, пока грузятся данные.
3. Пограничные случаи: истёкшая сессия, двойное нажатие на кнопку оплаты, слот, который заняли, пока клиент заполнял форму.
4. Тестовая среда с отдельным ботом и тестовой CRM, чтобы не засорять боевые данные.
5. Прогон сценариев сотрудниками заказчика.

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

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

Частые вопросы

Обсудим проект

Нужна похожая разработка?

Расскажите о задаче — уточним детали, предложим формат запуска и подготовим предварительную оценку. Это бесплатно.

Ваше имя Способ связиTelegramVKMAXТелефонПочта

Контакт

Отправить заявкуНаписать напрямую

Источники

• MAX API

Опубликовано 4 июля 2026 г. · Обновлено 12 октября 2026 г.