В прошлом году к нам пришли с запросом, который на старте звучал очень просто: "Нужно приложение, около 20 экранов, посчитайте бюджет". После двух встреч выяснилось, что внутри - личный кабинет, оплата, push, роли, бонусы, аналитика, интеграция с CRM и админка. Оценка выросла с 3,2 млн ₽ до 8,7 млн ₽, потому что стал виден реальный объем.
Я давно не считаю мобильные продукты "по экранам". Экран - это витрина. Основные деньги уходят в правила, данные, интеграции и в то, сколько будет стоить развитие через год. Если это увидеть до старта, можно срезать 30-40% лишних работ еще до первого спринта.
Иногда приложение вообще не нужно
У сервиса записи в локальные клиники был типичный запрос: сразу идти в iOS и Android. Мы пошли в мобильный веб на Laravel 11 + PostgreSQL 16 + PWA-оболочке, потому что сначала нужно было проверить повторные записи и оплату, а не собирать два клиента и проходить публикацию в сторах.
Запуск занял 6 недель. За первые месяцы сервис получил 2 000 записей, повторный визит был у 34% пользователей. После этого приложение уже имело экономический смысл: люди возвращались, push могли дать прирост, а стоимость установки окупалась.
Если пользователь заходит реже 1-2 раз в месяц, приложение часто только добавляет трение и удлиняет путь к оплате.
Здесь цифры говорят сами за себя: мобильный веб для проверки спроса стоит заметно дешевле, запускается быстрее и не требует держать бюджет на две платформы сразу.
Смету раздувают скрытые системы, а не макеты
У сети сервисных центров старт выглядел вполне невинно: каталог, кабинет, история заявок. После discovery всплыли интеграция с 1С, статусы ремонта в реальном времени, push, бонусы, роли клиента и менеджера, оплаты и возвраты. Бэкенд на Node.js 20 + NestJS и интеграции заняли около 55% работ. UI - меньше 25%.
До
- каталог
- кабинет
- история заявок
После проработки
- CRM и синхронизация с 1С
- push, бонусы, роли, права
- оплаты, возвраты, админка, события
Цена выросла не из-за "апсейла". Мы просто увидели весь проект. По рынку 2026 года ориентир у меня такой:
| Формат | Что внутри | Вилка |
|---|---|---|
| MVP | 1 сценарий, базовая оплата, простая админка | 2,5-5 млн ₽ |
| Продукт среднего уровня | роли, push, интеграции, аналитика | 5-12 млн ₽ |
| Сложная кастомная система | тяжелый бэкенд, много правил и обменов | от 12 млн ₽ |
Стек выбирают по экономике проекта
Когда срок жесткий, а спрос еще проверяется, кроссплатформа часто выигрывает. На b2c-проекте в доставке мы взяли Flutter 3.24 и выпустили MVP за 14 недель одной мобильной командой. Если бы шли в Swift и Kotlin отдельно, бюджет на входе был бы выше примерно на 25-35%.
У кроссплатформы при этом есть цена в будущем. На одном проекте мы когда-то выбрали ее "для экономии", а через несколько месяцев уперлись в нестандартную работу с гео и офлайном. Часть модулей пришлось переписывать, и выгода первого этапа почти исчезла. Я это хорошо запомнил: экономия на старте не всегда означает экономию на дистанции. На практике подход работает там, где сценарии и архитектура совпадают с возможностями стека.
Что обычно выбираем
- Swift + Kotlin - когда продукт держится на камере, Bluetooth, сложной анимации, офлайне
- Flutter - когда нужен быстрый релиз на двух платформах и единая команда
- React Native - когда у клиента уже сильная JS/TS-команда и много общей логики с вебом
MVP должен проверять деньги, а не амбиции
Самая дорогая ошибка - собирать v2 в первый релиз. Чат, реферальная механика, контент, уровни лояльности, несколько ролей, расширенная аналитика - все это хорошо смотрится на встрече, но почти всегда отодвигает запуск на месяцы.
У сервиса подписки на питание мы оставили только выбор программы, оплату, управление доставкой и push-статусы. Аналитику собрали в PostHog. Это сократило объем примерно на 38% и дало релиз за 10 недель вместо проекта на пять месяцев. Потом стало видно, что люди возвращаются ради переноса доставки, а не ради контентного раздела.
Что должно быть в первой версии
- один главный сценарий
- авторизация и базовая оплата
- события в аналитике
- админка только для обязательных операций
Хороший MVP режет не ценность, а лишние гипотезы.
Discovery окупается быстрее, чем кажется
Я редко оцениваю приложение без короткой подготовки. Обычно хватает 8-10 рабочих дней, чтобы снять самые дорогие иллюзии: роли, сценарии, интеграции, ограничения стора, публикацию, список API, метрику успеха на 90 дней.
Сколько это экономит?
Если discovery стоит 250-500 тыс. ₽, а потом убирает хотя бы один лишний модуль на месяц разработки, он окупается сразу. Для команды из 4-5 человек это обычно экономия от 700 тыс. ₽ и выше.
Что подготовить до оценки?
Роли пользователей, главный сценарий, список интеграций, ограничения по App Store Connect и Google Play Console, бюджет первой версии и метрику релиза на 90 дней. Этого уже хватает, чтобы разговор шел про деньги и сроки, а не про абстрактные "экраны".
В ближайшие 3 дня я бы сделал три вещи: выписал один сценарий, за который клиент платит деньги, отдельно отметил, что можно отложить на второй релиз, а потом попросил оценку в двух вариантах - мобильный веб и приложение. Очень часто самый дешевый экран в проекте - тот, который вы не стали разрабатывать.
