В прошлом году к нам пришел сервис доставки с ожиданием уложиться в 1,8 млн ₽. На первой встрече все звучало привычно: каталог, корзина, оплата, история заказов. После двух рабочих сессий список вырос до 3 ролей, карт с трекингом, операторского интерфейса, интеграции с ERP и админки. Первый релиз в итоге вышел на 4,9 млн ₽.
Я видел это много раз: бизнесу кажется, что он переплачивает за код, а по факту платит за собственную неопределенность. Когда продукт заранее раскладывают на сценарии, роли и интеграции, бюджет становится заметно спокойнее еще до договора.
Экранов мало, логики много
Снаружи два приложения могут выглядеть почти одинаково. Но одно - это каталог с оплатой, а второе - система, которая держит часть операционки бизнеса прямо в телефоне. Разница по цене между ними спокойно доходит до 2-4 раз.
Самая дорогая часть проекта - скрытая инженерия, которой не видно на макетах. Смотрите: авторизация через Apple ID и Google, push через Firebase и APNs, платежи, статусы заказов, роли пользователей, офлайн-кэш, обработка сетевых ошибок, публикация в App Store Connect и Google Play Console. Это не мелочи, а отдельные куски работы в мобильной части, бэкенде и QA.
У нас был B2C-сервис записи на стеке Flutter 3.27 + Laravel 11 + PostgreSQL 16. Снаружи - список услуг, карточка, оплата, профиль. Внутри - временные слоты, переносы, возвраты, промокоды, журнал операций и синхронизация с CRM. В таком составе это 14 недель. Без сложных статусов и интеграций уложились бы в 7-8 недель.
Цена растет не от экранов, а от того, сколько решений приложение принимает вместе с вашим бизнесом.
Платформа выбирается после ответа на один вопрос
Меня регулярно спрашивают: что дешевле - Flutter или нативно. Я бы начинал с другого вопроса: что именно должен проверить первый релиз через 2-3 месяца после запуска.
Если задача - быстро проверить спрос, я чаще выбираю Flutter. В 2026 году для MVP это все еще рабочий вариант: одна кодовая база, релиз быстрее, поддержка на старте проще. По срокам экономия обычно выходит в районе 20-35% по сравнению с двумя нативными командами.
Если продукт завязан на фоне, Bluetooth, сложной камере или постоянной геолокации, эта экономия быстро заканчивается. У нас был проект с трекингом курьеров, где пошли в React Native. На бумаге все выглядело нормально. Через 6 недель стало понятно, что нативные модули съедают весь выигрыш, архитектуру пришлось пересобирать, а потери составили почти 400 тыс. ₽. Это как раз тот случай, где мы изначально выбрали не лучший путь.
| Подход | Первый релиз | Бюджет | Доступ к функциям телефона | Поддержка |
|---|---|---|---|---|
| PWA | 4-8 недель | 600 тыс - 1,8 млн ₽ | ограниченный | проще всего |
| Flutter | 8-12 недель | 1,5-4 млн ₽ | высокий | одна кодовая база |
| React Native | 9-13 недель | 1,7-4,2 млн ₽ | зависит от пакетов | средне |
| Нативно iOS + Android | 12-18 недель | 3,5-8 млн ₽ | максимальный | дороже |
Бюджет ломает не ставка, а лишний MVP
Самый дорогой релиз - тот, в который пытаются уложить весь будущий продукт. Подписки, бонусы, чат, отзывы, кабинет партнера, рефералка, внутренняя CMS - по отдельности все выглядит безобидно. Вместе это легко добавляет месяцы работы.
Я обычно задаю клиенту короткий вопрос: какой ответ бизнес должен получить через 8-10 недель после запуска? Если ответ сформулирован нормально, состав MVP быстро трезвеет.
Мини-диалог обычно выглядит так:
- «Нам нужны бонусы, сертификаты и программа лояльности».
- «Что вы проверяете в первом релизе?»
- «Поймем, готовы ли люди записываться и платить».
- «Тогда оставляем запись, оплату, перенос визита и push. Остальное потом».
Так мы запускали сервис записи. Первый бюджет сократили на 38% и вышли в релиз за 11 недель. Через два месяца стало видно, что бонусы людям вообще не нужны, а семейные аккаунты нужны срочно.
Частая ошибка - собрать маленькую копию большого продукта. Правильнее собрать инструмент для проверки одной гипотезы.
Тише всего дорожают интеграции и админка
Дизайн редко недооценивают в разговорах, но почти всегда недооценивают в смете. Потому что дизайн - это не только экран. Сюда входят пустые состояния, ошибки, первый запуск, сценарии, ограничения iOS и Android, прототипы в Figma. Обычно здесь лежит 10-20% бюджета.
Интеграции почти всегда оказываются неприятнее ожиданий. CRM не отдает нужные поля. Платежка по-разному ведет себя на iOS и Android. 1С часто требует отдельную прослойку, чтобы мобильный клиент не лез напрямую в учетную систему.
И админка. Ее почему-то постоянно переносят на потом. Мы однажды так и сделали: мобильную часть собрали нормально, а серверную архитектуру и операторский интерфейс решили упростить. Через 4 месяца проект пришлось переделывать - каталог правили вручную, статусы расходились, команда клиента жила в Excel. После нормальной админ-панели и переработки бэкенда смета выросла еще на 40%+.
Дешевая смета часто означает дорогой вход
Когда я смотрю чужие предложения, меня интересует не итоговая цифра, а состав. Если в документе одна строка «мобильное приложение под ключ», я бы не стал воспринимать это всерьез. Нормальная смета разложена по слоям: аналитика, UX/UI, бэкенд, мобильная часть, QA, релиз, поддержка.
У нас был тендер, где мы выглядели дорогими: 3,8 млн ₽ против 1,4 млн ₽ у конкурента. Потом заказчик прислал чужое КП. Там просто не было QA, релиза, документации, Crashlytics, CI/CD и поддержки. Сравнивали не две сметы, а готовый продукт и обещание, что «приложение будет».
Перед запросом оценки просите у подрядчика не цену за приложение, а три вещи:
- список модулей и функций;
- что входит в расчет, а что вынесено за скобки;
- сколько стоит жизнь после релиза.
Если подрядчик не может объяснить, за какую неопределенность вы платите в первом релизе, это уже не смета. Это ставка на удачу. И вопрос здесь простой: вы сейчас покупаете продукт или право дорого ошибиться?
