Суперапп: что это и как разработать

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

Эталон жанра — WeChat: мессенджер, который вырос в среду, где живёт значительная часть повседневных цифровых действий. Из этого примера родилась и модель: внутри есть ядро (то, ради чего человек открывает приложение каждый день) и мини-приложения, которые ядро приводит к себе за счёт трафика и удобства.

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

Три модели, которые в обсуждениях называют одним словом.

Наблюдение, которое стоит знать перед тем, как копировать WeChat: крупные российские игроки — Сбер, Яндекс, VK, Т-Банк, Ozon — в основном развивают именно связанные приложения с общим аккаунтом и подпиской, а не одно суперприложение. Аналитики объясняют это и историей продуктов, и тем, что аудитория уже привыкла к отдельным приложениям под задачи.

Из свежих исключений — мессенджеры: Telegram последовательно движется к модели платформы с мини-приложениями, а платформа MAX изначально позиционируется как суперапп с авторизацией через «Госуслуги» и платежами через СБП.

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

Проверять стоит все три. Отсутствие любого делает проект дорогим экспериментом.

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

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

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

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

Самый практичный инструмент в этой теме — не свой суперапп, а мини-приложение внутри чужого. Mini App запускается по ссылке прямо в Telegram или VK: устанавливать ничего не нужно, авторизация и платежи — платформенные.

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

Чем платите: ограничениями платформы (что можно, что нельзя, какие платежи), зависимостью от правил, которые может поменять владелец, и меньшим контролем над данными и брендом.

Разумная стратегия для среднего бизнеса: мини-приложение как MVP сервиса, и уже по результатам — решение, нужно ли собственное приложение. Так проверяют не только идею, но и спрос на сценарий, который вы собирались добавлять внутрь.

Техническая часть, которую обзоры обычно пропускают. Суперапп — это не «много экранов», а платформа с правилами.

Ядро (оболочка). Отвечает за общее: навигацию, авторизацию, профиль, платежи, уведомления, аналитику, обновления. Ядро не знает бизнес-логику сервисов, но предоставляет им общие возможности.

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

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

Совместная инфраструктура. Единая аналитика с событиями по всем сервисам, общая система дизайна, чтобы разделы не разъезжались, и один механизм обновлений.

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

Если внутрь вашего приложения должны попасть сторонние сервисы, к архитектуре добавляется отдельный слой. Он состоит из четырёх обязательных частей.

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

SDK и разрешения. Набор возможностей, которые вы даёте: профиль (что именно из него видно), платежи, уведомления, геолокация, камера. Каждая возможность запрашивается явно.

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

Расчёты. Как делится выручка, кто выставляет документы, как проходят возвраты и как считать конверсию по каждому мини-аппу.

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

Самая недооценённая часть проекта: люди думают о навигации, а месяцы уходят сюда.

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

Авторизация. Один вход, восстановление доступа, двухфакторная аутентификация, для корпоративных сценариев — SSO. Плюс требования к персональным данным и хранению в России.

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

Согласия и приватность. Пользователь должен понимать, кому и какие данные передаются при переходе в мини-приложение. Это одновременно требование закона и вопрос доверия.

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

Плата за единый интерфейс, о которой узнают на третьем сервисе.

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

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

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

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

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

Никто не строит суперапп сразу. Работающая последовательность выглядит так.

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

Шаг 2. Второй сервис внутри как модуль. Выбирается тот, который нужен той же аудитории и логично продолжает основной сценарий. Здесь и проверяется гипотеза перетока.

Шаг 3. Общий профиль и платежи. Аккаунт, оплата, подписка, аналитика — на этом шаге вы получаете экосистему даже без единого приложения.

Шаг 4. Платформа для внешних мини-аппов. Только когда есть аудитория и партнёры, готовые заходить.

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

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

Ориентиры по нашим работам: мобильное приложение — от 1,8 млн ₽, продукт под бизнес-процесс с серверной частью — от 1,7 млн ₽, интеграция с внешней системой (платежи, учёт, идентификация) — от 150 тыс. до 1,5 млн ₽ за одну. Полноценная платформа мини-приложений с песочницей, SDK и модерацией — это уже не одна смета, а программа работ на несколько этапов.

Честно про наш опыт: полноценных супераппов мы не строили. Мы делаем сервисы внутри экосистем и модульные приложения — среди проектов VK Fest, Petshop Выгул, GigAnt. Это ровно те первые два шага, на которых обычно и находится задача. Что нужно именно вам, видно после разбора сценариев — оценка проекта бесплатная: расскажите про продукт.

Строить суперапп без частотного ядра. Набор редких сервисов в одной оболочке не даёт ни удержания, ни перетока — только рост стоимости релизов.

Копировать WeChat. Он вырос в другой рыночной ситуации, где мобильный интернет и платежи развивались внутри одной платформы. Повторить путь, а не форму, невозможно.

Начинать с платформы для партнёров. Песочница, SDK и модерация без очереди внешних сервисов — расходы без выручки.

Сшивать сервисы в монолит. Если модули не изолированы, каждый релиз становится дороже предыдущего, а падение одного сервиса роняет всё приложение.

Экономить на профиле и платежах. Это фундамент; переделка после запуска означает миграцию аккаунтов и платёжной истории.

Мерить установки вместо связности. Пока доля пользователей двух и более сервисов низкая, суперапп существует только на схеме.

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

Если ответы говорят «ядро есть, аудитория общая» — начинайте со второго сервиса внутри существующего приложения и модульной архитектуры. Если ядра нет — сначала оно, а мини-приложение в Telegram или VK поможет проверить спрос на новый сценарий за небольшие деньги.