Сколько стоит мобильное приложение в 2026 году: почему сметы отличаются втрое

На столе две сметы на одно и то же приложение. В одной 1,6 млн ₽, в другой — 4,65 млн. Бриф общий, обе цифры взяты из реальных проектов, а разница — почти втрое.

Разберем, что прячется за строкой «мобильное приложение», какие работы в неё не входят и как свести два таких предложения к сравнимому виду.

Цифры не из переговоров: летом 2026 года вышли два исследования российского рынка. В выборке AppFox медианная стоимость MVP — 1,6 млн ₽, в анализе 41 коммерческого предложения WhiteTigerSoft медиана — 4,65 млн ₽.

Обе цифры взяты из реальных смет. Для сравнения из первой выборки взяли медиану MVP, а во второй посчитали полный цикл: аналитику, дизайн, разработку, бэкенд, тестирование и стартовую поддержку. Такой разрыв появляется из-за продуктов разного размера, спрятанных за одним словом «приложение»; ставка здесь вторична.

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

Восемь экранов могут стоить дороже двадцати

Количество экранов помогает оценить дизайн и часть мобильной разработки. Оно почти ничего не говорит о правилах за интерфейсом.

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

С офлайн-режимом та же история. В интерфейсе это плашка «Нет сети». Android Developers описывает offline-first как архитектуру с локальным и сетевым источниками данных и синхронизацией между ними. На практике нужны локальное хранилище, очередь изменений и правила разрешения конфликтов. Поэтому один экран заказа может стоить по-разному для каталога, службы доставки и сервиса, который должен работать в горах без связи.

Из одной строки в смете вырастают четыре блока

1. Счёт начинается до первой строки кода

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

Попытка заменить этот этап созвоном экономит деньги до первого вопроса разработчика: «Что делать с заказом, если оплата прошла, а 1С не ответила?» Если ответа нет, решение всё равно придётся принимать. Позже такая неопределённость обойдётся дороже.

2. Две платформы остаются даже с одной кодовой базой

Сюда входят интерфейс, навигация, локальные данные, push-уведомления и работа с камерой, геолокацией или Bluetooth. Flutter позволяет выпускать iOS- и Android-приложения из одной кодовой базы. Где на этом действительно появляется экономия, мы разбирали отдельно. При похожих сценариях это снижает объём дублирующей разработки. Две платформы всё равно требуют отдельных сборок, разрешений и тестирования на устройствах.

3. «Простая админка» заканчивается на тысяче товаров

Сервер хранит пользователей, заказы, права и платежи. Админка позволяет сотрудникам управлять ими без обращения к разработчикам. В выборке WhiteTigerSoft серверная часть вместе с API и админкой занимала 30–45% трудозатрат.

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

4. Экран готов, релиз ещё нет

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

Четыре решения меняют итог сильнее ставки

Первая причина — роли. Клиент оплачивает заказ, курьер меняет статус, оператор решает спор, администратор управляет доступами. Формально это одно приложение. По объёму правил и тестов — четыре разных маршрута.

Вторая — интеграции. С публичным API команда заранее видит методы и ошибки. Внутренняя система десятилетней давности иногда раскрывается только через сотрудника, который «помнит, почему тут так». До оценки стоит запросить документацию, тестовый доступ и владельца интеграции со стороны заказчика.

Третья — офлайн. В проекте Alps2Alps водители выполняют трансферы в Альпах, где связь пропадает на маршруте. Приложение хранит заказы и маршруты на устройстве, а после возвращения сети синхронизирует изменения. Весь мобильный контур сократил обработку заказа с 4,5 минуты до 45 секунд, а обращения в поддержку — с 450 до 140 в месяц. Эти результаты относятся ко всей системе, а не к одному офлайн-режиму.

Четвёртая — срок. Часть работ можно вести параллельно, но добавление людей не сокращает календарь бесконечно. Ускорение требует больше координации и оставляет меньше запаса на неизвестные. Дату, привязанную к сезону или мероприятию, нужно назвать до оценки. За три недели до релиза она превращается в стресс-тест для команды и бюджета.

Иногда мобильная строка в первой версии не нужна

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

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

Дешёвая смета может считать половину продукта

В одном предложении подрядчик оценил дизайн, Flutter-клиент и публикацию. Сервер предоставляет заказчик, админки нет, интеграции посчитают после знакомства с API. В другом предложении учтены аналитика, бэкенд, кабинет сотрудников, 1С, тестирование и мониторинг. Суммы закономерно отличаются в несколько раз.

Перед сравнением приведите предложения к одинаковому составу и задайте семь вопросов:

1. Какие роли и пользовательские сценарии включены?

2. Кто разрабатывает бэкенд и админку?

3. Какие интеграции уже оценены?

4. Для каких платформ и версий ОС готовится релиз?

5. Какие виды тестирования входят в стоимость?

6. Что команда передаст после запуска: код, документацию, доступы и сборки?

7. Как считаются новые требования и поддержка после релиза?

Если ответы разбросаны по переписке, попросите собрать их в одну смету. Иначе через два месяца придётся восстанавливать сюжет по сообщениям «мы думали, это входит».

Четыре коридора для первого бюджета

В анализе 41 коммерческого предложения WhiteTigerSoft проекты распределены по четырём диапазонам:

1,1–2 млн ₽ — простой каталог или информационное приложение;

2–4 млн ₽ — бизнес-приложение с заказами, кабинетом и оплатой;

4–6 млн ₽ — сложный продукт с интеграциями, ролями и аналитикой;

6–16 млн ₽ — многосторонняя или корпоративная платформа.

Диапазоны отражают одну выборку WhiteTigerSoft. Бюджет конкретного проекта Qtim рассчитывает отдельно.

После релиза понадобятся обновления, мониторинг, инфраструктура и исправления. В исследовании AppFox поддержка первого года в среднем составила 18% первоначального бюджета. Это показатель одной выборки; точный резерв зависит от нагрузки, внешних сервисов и темпа обновлений.

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