Недавно на созвоне с ритейл-клиентом мы обсуждали Flutter, публикацию и бюджет около 2,4 млн ₽. Запрос звучал уверенно: «Хотим приложение, у конкурентов уже есть». Когда подняли аналитику, картина оказалась проще: 83% мобильного трафика шло из поиска и рекламы, а основная просадка была в форме заказа на смартфоне. Люди не ждали app - им было неудобно купить.
По сути, вопрос почти всегда один: где клиенту проще сделать целевое действие - в браузере за 20 секунд или в установленном продукте, который он действительно будет открывать снова.
Сначала считаем частоту, потом беремся за разработку
Если человек приходит 1-2 раза в месяц из поиска, карт, рекламы или соцсетей, адаптивный сайт почти всегда выигрывает. Не нужно ничего устанавливать, путь до оплаты короче, SEO начинает работать сразу. Для малого и среднего бизнеса этого часто достаточно, чтобы закрыть заявки, запись, каталог и оплату.
Приложение начинает приносить деньги там, где сценарий повторяется: доставка, бонусы, личный кабинет, запись в пару тапов, подписка, повтор заказа. В таких кейсах важны push, сохраненные карты, быстрый вход, история действий, а иногда и совсем простая вещь - сохраненный адрес без ручного ввода.
У сервиса доставки еды под NDA повторные клиенты давали 68% оборота. На мобильном сайте люди теряли корзину, заново выбирали адрес и дольше входили в аккаунт. Мы собрали приложение на Flutter 3.29 с Laravel 11 на бэкенде, добавили экран «повторить заказ», биометрию и оплату в один шаг. За 14 недель получили рост повторных заказов на 14%.
Мини-диалог тут обычно короткий:
- Нам точно нужно приложение?
- Сколько у вас повторных действий на клиента в месяц?
- Не считали.
- Значит, начинать надо с аналитики, а не со store.
Хороший мобильный сайт часто дает деньги быстрее
У сети клиник был как раз такой случай. Изначально обсуждали iOS и Android, но мобильная запись ломалась еще до идеи приложения: форма на 9 полей, длинный скролл, ручной ввод карты, мелкие кнопки.
Мы переработали мобильный сценарий за 5 недель. Оставили 3 поля, добавили Apple Pay и Google Pay, перестроили экран под работу одной рукой.
До/после
- было: форма из 9 полей, конверсия мобильной записи ниже desktop на 41%
- стало: 3 поля, оплата в 1 шаг, рост mobile CR на 27%
- бонусом: стоимость лида снизилась на 18%
Это типовая история. Пока мобильный путь сырой, приложение просто переносит ту же проблему в другой контейнер. У нас был такой промах в B2B-сервисе: быстро сделали MVP под две платформы, а потом увидели, что трафик холодный, визиты редкие, установок мало. Сайт все равно остался главным каналом, и дорабатывать в итоге пришлось именно его.
Цена разработки сама по себе почти ничего не решает
Вопрос «сколько стоит приложение» имеет смысл только после цифр по удержанию и повторным действиям. Считать нужно не чек на разработку, а стоимость результата: заказа, возврата клиента, роста LTV.
Грубо говоря, серьезная мобильная переработка сайта сейчас обычно стоит 600 тыс. - 1,8 млн ₽. MVP-приложение чаще обходится в 2,5-4 млн ₽, плюс поддержка около 15-25% в год. Если приложение поднимает повторные покупки хотя бы на 10-15%, его экономика на дистанции может оказаться лучше сайта.
Если:
repeat_purchase_rate растет
retention_90 держится
LTV возвращаемого клиента покрывает CAC и поддержку,
то приложение считаем каналом роста.
Иначе сначала чиним мобильный сайт.
| Формат | Срок | SEO | Push | Доступ к функциям устройства | Поддержка |
|---|---|---|---|---|---|
| Адаптивный сайт | 4-8 недель | Да | Нет | Базовый | Низкая |
| PWA | 6-10 недель | Да | Частично | Средний | Средняя |
| Flutter / React Native | 10-18 недель | Нет | Да | Высокий | Средняя |
| Нативно | 14-24 недели | Нет | Да | Максимальный | Высокая |
PWA и приложение - это уже второй ход, не первый
PWA я бы рассматривал как промежуточный шаг, когда бизнесу нужно быстро проверить возвраты, браузерные пуш-уведомления и сценарий с иконкой на главном экране. Это нормальный вариант, если кабинет несложный и нет плотной работы с камерой, гео, Bluetooth или офлайн-режимом.
Flutter чаще оправдан, когда нужно быстро выйти на две платформы с одним кодом и удержать разумный бюджет. Нативную разработку мы берем там, где важны производительность интерфейса, сложные жесты, финоперации, трекинг в реальном времени или тяжелая интеграция с устройством.
Я обычно задаю клиенту пять вопросов перед стартом:
- какая доля мобильного трафика и как mobile CR отличается от desktop;
- сколько повторных действий на пользователя в месяц;
- есть ли реальная причина установить app уже сейчас;
- уперся ли сайт в потолок по UX;
- кто будет развивать продукт после релиза.
Нормальный путь почти всегда идет поэтапно
Рабочая схема простая: сначала сильный адаптивный сайт, потом мобильный UX, кабинет, возвраты через push или PWA, и только после этого приложение для ядра аудитории. Такой маршрут дешевле ошибки и лучше выдерживает проверку цифрами.
Самое дорогое приложение - то, которое приятно показывать на встречах и почти никто не открывает на второй неделе. У вас сейчас проблема в отсутствии app или в том, что клиенту до сих пор неудобно купить с телефона?
