Конструктор мобильных приложений или своя разработка: где кончается коробка

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

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

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

Коробка и своя разработка коротко

Коробка — готовое приложение на платформе вендора. Магазин подключает к общему шаблону каталог, оплату и доставку и платит подписку. Конструктор мобильных приложений устроен похоже, только приложение из готовых блоков собирают сами.

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

Где кончается коробка

Шесть самых типичных ситуаций из нашей практики. Если вы узнали свой бизнес в нескольких из них, пора считать затраты.

1. Релизы идут месяцами. Доработка ждёт своей очереди у вендора. Нам называли срок релиза 1–2 месяца.
2. Кастомизация есть только на словах. Платформа обещает доработки под клиента, но они идут так долго, что до релиза не доходят. Интерфейс меняется только в рамках шаблона.
3. Обновления шаблона ломают ваши функции. Шаблон общий для всех клиентов вендора. Его обновляют под других, и то, что работало у вас, ломается без вашего контроля. Исправления и доработки платные и идут с задержкой.
4. Бренд теряется. Приложение похоже на десятки других магазинов на той же платформе, и характер бренда в нём не виден.
5. Новые клиенты не попадают в приложение. В учётной системе всё готово: методы регистрации новых клиентов в API 1С есть. Но в коробочном приложении их не реализовали. Как приложение и сайт обмениваются данными с 1С, мы разбирали в статье об интеграции 1С с сайтом и приложением.
6. Сценарии бизнеса не помещаются в шаблон. Запись на услугу в салоне, персональные рекомендации, подписочная модель — если платформа этого не умеет, механику придётся ждать или обходить.

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

Когда хватит коробки или конструктора

Выбор «конструктор или разработка приложения» не всегда решается в пользу разработки. Коробка остаётся разумным выбором в четырёх случаях.

1. Нужно проверить гипотезу. Будут ли покупатели заказывать через приложение, можно проверить на коробке или в no-code-конструкторе. Своя разработка понадобится, когда гипотеза подтвердится.
2. Сценарий покупки типовой. Покупателю хватает каталога, поиска, корзины, оплаты и доставки. Какие механики приложения добавляют магазину выручку сверх этого, мы разбирали в статье о приложении для интернет-магазина.
3. Приложение даёт небольшую долю продаж. Своё приложение стоит делать, когда через него идёт заметная доля продаж, а развитие зависит от вендора.
4. Развивать приложение пока некому. После релиза своё приложение требует продуктовых решений и бюджета на развитие. Если плана развития нет, подписка на платформу проще в управлении.

Как сравнить затраты за три года

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

Суммы у каждой компании свои, поэтому сравним статьи затрат.

Чтобы посчитать на своих цифрах, сложите по каждому варианту:

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

Отдельно оцените выручку, которую не приносят функции из очереди вендора. Её достаточно прикинуть по одной механике, например по комплектам или подписке.

Как перейти с коробки по шагам

Уходить с коробки можно по частям. Сайт при этом менять не обязательно.

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

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

На втором шаге сайт и приложение проектируют на общей модели каталога, цен и заказов. Тогда новую функцию делают один раз сразу для обоих каналов. Как перенести сам сайт, мы описали в статье о том, как уйти с 1С-Битрикс.

До оценки проверьте три вещи:

• Аккаунт в магазине приложений. Если вы управляете карточкой приложения, идентификаторами и подписью сборок, новое приложение выйдет обновлением старого. Если нет, для покупателей готовят отдельный переход.
• Где хранятся аккаунты и история заказов. Если история заказов хранится в системе магазина, новое приложение получит её через существующие интерфейсы.
• Состав первой версии. Какие функции нужны покупателям в первый день, а какие подождут следующего релиза.

Как мы перезапускали приложения ритейлеров

Что мы уже сделали по перезапуску приложений:

• Бетховен. Сеть зоомагазинов ушла с коробки на своё приложение. Перед перезапуском приложения мы поговорили с десятками покупателей, потом упростили каталог и оформление заказа и добавили профиль питомца с напоминаниями о покупках. Конверсия в покупку выросла с ~5% до 15%, через приложение идёт 40% заказов.
• LOVE REPUBLIC. За 5 месяцев мы перезапустили приложение бренда на Flutter и выпустили его к главной распродаже года. Через приложение идёт 30% всех покупок.

Что делать с вашей коробкой

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

С этим мы и помогаем. Переносим приложение с коробки на Flutter, а аккаунты в App Store и Google Play и данные покупателей остаются у вас. Срок фиксируем после короткого обследования: 3 месяца — для согласованного состава первой версии, публикация зависит ещё от модерации магазинов приложений.

Для первого разговора достаточно ссылки на приложение и ваших целей.