Если коротко, то цены выглядят так:
| Приложение | Что внутри | Стоимость | Срок |
|---|---|---|---|
| MVP | 5–8 экранов, iOS и Android, вход, работа с API | от 2,1 млн ₽ | 2–3 месяца |
| Среднее | свой бэкенд, админ-панель, оплата, push-уведомления | 6–7 млн ₽ | 4–5 месяцев |
| Сложное | маркетплейс, финтех, офлайн-режим, много ролей | от 15 млн ₽ | от 8 месяцев |
Это средние цифры по Москве и Санкт-Петербургу. Итог зависит не столько от числа экранов, сколько от того, что стоит за ними: где хранятся данные, сколько ролей у пользователей, с какими системами приложение обменивается информацией. Разберём главные статьи расходов по очереди.
Мобильное приложение — это не только экраны
Пользователь видит интерфейс в телефоне. Заказчик платит за всю систему, в которой этот интерфейс — только верхний слой. Обычно в неё входят:
- само приложение для iOS и Android;
- бэкенд — сервер, база данных, логика, которая работает, даже когда приложение закрыто;
- админ-панель — веб-интерфейс, где сотрудники заказчика управляют контентом, заказами и пользователями;
- интеграции — платежи, CRM, учётная система, службы доставки, карты;
- инфраструктура — серверы, сборка и выкладка новых версий, мониторинг.
Простое приложение может обойтись без своего бэкенда, если данные уже отдаёт существующая система по API. Поэтому MVP и стоит заметно дешевле: команда делает экраны и подключается к готовому. Как только нужен собственный сервер с логикой и админкой, проект переходит в другую весовую категорию.
Платформы: одна кодовая база или две
iOS и Android — разные операционные системы со своими правилами, языками и магазинами приложений. Исторически под каждую писали отдельное приложение, и это почти удваивало бюджет на клиентскую часть.
Кроссплатформенная разработка решает это иначе: одно приложение на Flutter собирается и для iOS, и для Android. Код, дизайн и логика общие, а тестировать и публиковать приходится всё равно две версии. Для большинства бизнес-приложений — личных кабинетов, заказов, внутренних сервисов для сотрудников — такой подход даёт примерно тот же результат для пользователя заметно дешевле, чем две нативные команды.
Нативная разработка оправдана реже: когда приложение глубоко работает с оборудованием телефона, нужна предельная производительность графики или есть особые требования платформы. Об этом стоит поговорить на этапе оценки, а не после первого релиза.
Бэкенд и админ-панель
Самая недооценённая часть бюджета. Приложение для заказов выглядит как десяток экранов, но за ними стоят каталог, корзина, расчёт цены, оплата, статусы, уведомления, роли сотрудников и отчёты. Всё это живёт на сервере.
На стоимость бэкенда влияют:
- число ролей — клиент, курьер, менеджер и администратор видят разное и могут разное;
- оплата — подключение платёжного сервиса, возвраты, чеки;
- уведомления — push, SMS, письма, и правила, когда что отправлять;
- обмен данными с вашими системами: чем их больше и чем хуже у них документация, тем дольше работа;
- нагрузка — сто пользователей в день и десять тысяч одновременно требуют разной архитектуры.
Админ-панель часто воспринимают как мелочь «для своих». Но именно в ней сотрудники проводят рабочий день, и неудобная админка съедает время команды заказчика каждый день после запуска.
Дизайн
Дизайн мобильного приложения — это не только цвета и шрифты. Это сценарии: сколько шагов до заказа, что видит пользователь без интернета, как выглядит ошибка оплаты, куда ведёт push-уведомление.
Стоимость дизайна зависит от числа экранов и состояний, а не от «красоты». У каждого экрана есть пустое состояние, загрузка, ошибка, и всё это нужно нарисовать, иначе разработчик придумает сам. Хороший дизайн экономит деньги на разработке: решения принимаются на макете, где поменять кнопку стоит минуты, а не в коде, где это стоит дни.
Что делает приложение сложным
Ценник от 15 млн ₽ появляется не из-за большого числа экранов. Обычно причина в одном из таких требований:
- маркетплейс — несколько сторон сделки, у каждой свой интерфейс, расчёты между ними, споры и возвраты;
- финансовые операции — повышенные требования к безопасности, журналу действий и проверкам;
- офлайн-режим — приложение работает без связи и потом синхронизирует данные, не теряя и не дублируя их;
- много ролей и прав — каждая роль умножает экраны, проверки и тесты.
Такие проекты занимают от восьми месяцев. Их почти всегда разумно начинать с MVP и проверять на реальных пользователях, прежде чем строить всё целиком.
Жизнь после запуска
Публикация в App Store и Google Play — не конец расходов. Приложение живёт в среде, которая меняется без вашего участия: выходят новые версии iOS и Android, магазины обновляют правила, сторонние сервисы меняют API.
После запуска обычно нужны:
- исправление ошибок, которые нашлись на реальных пользователях; в гарантийный срок это бесплатно — у нас гарантия 6 месяцев;
- обновления под новые версии операционных систем и требования магазинов;
- развитие — новые функции по данным аналитики и отзывам пользователей;
- инфраструктура — серверы, хранилище, платные сервисы уведомлений и карт.
Планируйте бюджет на развитие с самого начала. Приложение, которое не обновляется, через год начинает выглядеть заброшенным, а иногда и перестаёт проходить проверку магазинов.
Как удержать бюджет
Несколько решений помогают не выйти за рамки:
- Начать с MVP. 5–8 экранов вокруг одного главного сценария — и через 2–3 месяца у вас реальные пользователи, а не предположения.
- Выбрать Flutter, если нет причин для нативной разработки: одна кодовая база на две платформы.
- Использовать готовые сервисы для входа, платежей, карт и уведомлений вместо собственной разработки.
- Согласовать дизайн до разработки. Изменения на макете дешевле изменений в коде.
- Смотреть на демо каждые две недели. Так видно, куда уходят деньги, и можно вовремя поменять приоритеты.
Оценку сроков и стоимости мы делаем бесплатно, за 1–3 дня после разговора о задаче. Подробнее о том, как мы делаем приложения на Flutter, — на странице разработки мобильных приложений.
Цена приложения складывается из того, чего пользователь не видит. Экраны — лишь видимая часть. Остальное и решает, сколько будет стоить проект.
