На вопрос о стоимости мобильного приложения честный ответ звучит как «от нескольких сотен тысяч до нескольких миллионов». Он верен и совершенно бесполезен: разброс определяется не рынком, а составом работ, о котором на старте ещё никто не договорился. Полезнее разобрать смету по частям и понять, какие решения двигают итоговую цифру сильнее всего. Ниже — структура бюджета в том виде, в каком мы обсуждаем её с заказчиком до начала проекта.
Из чего складывается смета
Доли ниже ориентировочные, они заметно смещаются в зависимости от проекта. Но соотношение частей помогает понять, где именно прячутся деньги, и не удивляться, когда серверная часть оказывается сопоставима по трудоёмкости с самим приложением.
| Статья работ | Доля бюджета | От чего зависит |
|---|---|---|
| Проектирование и дизайн | 15-25% | Число экранов, доля нестандартных сценариев, наличие готового бренда |
| Разработка клиентской части | 35-50% | Одна платформа или две, сложность интерфейса, анимации |
| Серверная часть и API | 15-30% | Есть ли готовый бэкенд или всё пишется с нуля |
| Тестирование | 10-15% | Разнообразие устройств и версий систем, требования к надёжности |
| Публикация и запуск | около 5% | Подготовка материалов и прохождение проверки в магазинах приложений |
Если в смете отсутствует какая-то из строк, это не значит, что работы не будет. Это значит, что её оплатят позже и внепланово.
Что удорожает проект сильнее всего
Несколько решений увеличивают бюджет кратно, а не на проценты. Их стоит обсудить в первую очередь.
- Две нативные разработки вместо кросс-платформенной. Приложение под iOS и Android, написанное отдельно на каждой платформе, почти удваивает стоимость клиентской части и последующую поддержку.
- Платежи и подписки. Правила магазинов приложений строже, чем на сайте: часть сценариев обязана идти через встроенные покупки, и это отдельная работа с логикой, восстановлением покупок и проверкой на сервере.
- Работа офлайн и синхронизация. Самая недооценённая часть. Хранение данных на устройстве, разрешение конфликтов при одновременном изменении, поведение при обрыве связи — это полноценная подсистема.
- Нестандартный интерфейс. Каждая собственная анимация и каждый нетиповой элемент — отдельная задача, которую нельзя закрыть готовым компонентом платформы.
- Интеграции. Учётная система, карты, оборудование, сканирование документов. Стоимость определяется не приложением, а состоянием той системы, с которой предстоит связываться.
Что позволяет уложиться в меньший бюджет
Экономия здесь не про снижение ставки, а про сокращение состава первой версии. Рабочие способы:
- Начать с одной платформы — той, где сейчас больше ваших пользователей. Вторая добавляется, когда продукт подтвердил спрос.
- Использовать типовые элементы интерфейса платформы вместо собственных. Пользователи их уже знают, а разработка идёт быстрее.
- Выпустить сокращённую версию с одним ключевым сценарием и дополнять её по данным реального использования.
- Проверить гипотезу веб-приложением или адаптивным сайтом, если возможности устройства пока не нужны.
- Опереться на существующий бэкенд, если он уже есть, вместо параллельной разработки новой серверной части.
Отдельно отметим первый пункт. Кросс-платформенная разработка закрывает большинство задач бизнеса, а переход к нативной оправдан там, где нужны сложная графика, тяжёлая работа с камерой или специфические возможности системы.
Расходы, которые начинаются после релиза
Приложение — не разовая покупка, и это главная неожиданность для тех, кто считает бюджет один раз. Каждый год выходят новые версии операционных систем, меняются требования магазинов, устаревают библиотеки и сертификаты. Без сопровождения продукт через полтора-два года начинает вести себя странно на новых устройствах, а затем перестаёт проходить проверку при очередном обновлении.
В постоянные расходы входят: продление аккаунтов разработчика в магазинах, серверная инфраструктура и её масштабирование, обновления под новые версии систем, исправление ошибок, доработки по обратной связи пользователей. Разумный ориентир — закладывать на сопровождение заметную долю от стоимости разработки ежегодно. Конкретная величина зависит от нагрузки и числа интеграций, но нулевой она не бывает.
Что часто забывают включить в бюджет
Помимо самой разработки есть работы, которые всплывают ближе к релизу и портят план. Их разумно назвать сразу.
- Подготовка материалов для магазинов приложений: описания, скриншоты под разные размеры экранов, политика конфиденциальности, ответы на вопросы о работе с данными.
- Аналитика: без неё нельзя понять, какими сценариями пользуются, а какие сделаны зря.
- Уведомления: их настройка выглядит мелочью ровно до момента, когда требуется сегментация и расписание.
- Панель управления контентом, если данные в приложении меняются чаще, чем выходят обновления.
- Прохождение проверки в магазинах: отказ по формальной причине означает исправление и повторную подачу.
Почему оценки разных подрядчиков отличаются в разы
Чаще всего дело не в жадности, а в разном понимании задачи. Одна команда посчитала приложение с авторизацией по номеру телефона и списком товаров, другая — то же приложение с офлайн-режимом, уведомлениями, встроенными покупками и панелью управления. Формально обе отвечали на один вопрос.
Вторая причина — что включено в цифру: дизайн, тестирование, публикация, исправление ошибок после релиза, аналитика. Третья — форма договора. Фиксированная стоимость обычно содержит запас на риски, почасовая оплата выглядит дешевле на старте, но требует управляемого объёма работ и дисциплины с обеих сторон.
Как получить смету, которой можно пользоваться
Мы просим заказчика требовать от любого подрядчика, включая нас, одного и того же: разбивки по этапам и по экранам, а не одной итоговой суммы. Тогда видно, что можно убрать из первой версии, а что действительно необходимо, и разговор о бюджете превращается в разговор о составе работ.
- Перечень экранов с указанием сложности каждого.
- Список интеграций и условие, что делает подрядчик, а что — владелец смежной системы.
- Состав тестирования: какие устройства и версии систем проверяются.
- Что происходит после релиза и на каких условиях.
- Что не входит в смету — этот пункт важнее остальных.
Оценка без описания состава работ — это не смета, а обещание. С разбивкой по этапам разговор становится предметным, и первую версию почти всегда удаётся собрать дешевле, чем казалось на старте.
Если нужно понять порядок бюджета под конкретную задачу, начните с описания сценариев и списка экранов — этого достаточно для предварительной оценки. Мы разберём задачу и предложим, с чего начать: иногда выгоднее сначала разработать веб-приложение и проверить спрос, а к нативной разработке перейти, когда сценарии подтвердятся.
