Почему «цена приложения» ничего не говорит
Вопрос «сколько стоит приложение» без описания сценариев устроен так же, как вопрос «сколько стоит дом». Ответ зависит не от отрасли, а от того, что именно вы хотите получить: площадь, материалы, коммуникации, сроки. В разработке роль площади играет набор пользовательских путей, которые должны работать.
Два проекта с одинаковым описанием «приложение для записи на услуги» могут отличаться в пять раз. В первом клиент видит список услуг, выбирает время и оставляет заявку. Во втором — видит расписание конкретного мастера, оплачивает онлайн, переносит запись, получает напоминание, а администратор подтверждает слоты из панели. Первый проект — это несколько экранов. Второй — продукт с ролями, расписанием, оплатой и уведомлениями.
Поэтому корректная постановка вопроса звучит иначе: сколько стоит вот этот набор сценариев в этой версии продукта. Чем раньше вы его зафиксируете, тем меньше вероятность, что итоговая сумма окажется вдвое больше ожидаемой — и тем проще сравнивать предложения разных подрядчиков между собой.
В 7АРТ стартовая цена разработки приложения — от 149 900 ₽ за первый релиз. Это ориентир для проекта с согласованным списком экранов и сценариев, а не фиксированная цена «приложения вообще»: итог зависит от состава работ, и он фиксируется в договоре.
Из чего складывается стоимость
Смета на приложение почти всегда состоит из одних и тех же блоков. Разница — в их наполнении. Полезно понимать, за что вы платите, чтобы не сравнивать предложения по одной цифре в конце письма.
- Аналитика и сценарии. Описание ролей, пользовательских путей и состояний: что видит человек при пустом списке, при ошибке оплаты, без интернета. Этот этап почти не виден в готовом продукте, но именно он определяет объём работ.
- Прототип и дизайн. Схема экранов, затем макеты. Вариант «интерфейс на основе шаблона» дешевле индивидуальных макетов по каждому экрану, но подходит не для любого продукта.
- Клиентская часть. Экраны, навигация, работа с формами, локальное хранение, обработка ошибок. Здесь же решается, делаем мы нативную разработку под iOS и Android или кроссплатформенную.
- Серверная часть. API, база данных, авторизация, права, очереди, журнал действий. Приложение без сервера — редкость: даже каталог услуг нужно откуда-то получать.
- Интеграции. Оплата, push-уведомления, карты, CRM, 1С, внешние API, аналитика. Каждая интеграция — отдельный объём с собственными ограничениями и тестовым контуром.
- Публикация и запуск. Подготовка сборок, скриншоты и описания, аккаунты разработчика, прохождение проверки магазинов, мониторинг первых дней.
| Блок работ | Что даёт | Как влияет на цену |
|---|---|---|
| Аналитика | Список сценариев и состояний | Чем больше ролей и веток, тем больше объём |
| Дизайн | Макеты или адаптация шаблона | Индивидуальные макеты дороже шаблонных |
| Клиент | Экраны и логика на устройстве | Две платформы — две кодовые базы или кроссплатформа |
| Сервер | API, данные, права доступа | Зависит от объёма данных и числа ролей |
| Интеграции | Оплата, push, CRM, 1С | Каждая система — отдельная работа и тесты |
| Публикация | Сборки в App Store и Google Play | Требования магазинов и сроки проверки |
Три уровня продукта — и разная цена
Практичнее выбирать не между «дорого» и «дешево», а между уровнями зрелости продукта. Первый релиз не обязан закрывать всё: чаще выгоднее проверить гипотезу на узком сценарии и расширять его по факту использования.
| Уровень | Что входит | Когда имеет смысл |
|---|---|---|
| Проверка гипотезы | Несколько ключевых экранов, один основной сценарий, минимум интеграций | Нужно проверить, пользуются ли этим вообще, до серьёзных вложений |
| Рабочая версия | Полный основной сценарий, авторизация, оплата, уведомления, админка для сотрудников | Продукт уже приносит деньги и должен работать без ручной поддержки |
| Продукт с интеграциями | Обмен с CRM и 1С, роли, отчёты, офлайн-режим, несколько платформ | Процессы компании завязаны на учётные системы, ошибки стоят дорого |
Переход между уровнями — это не «доплата за то, что не сделали сразу», а нормальный путь развития продукта. Плохо, когда первый релиз пытаются превратить в третий: сроки растут, запуск откладывается, а гипотеза так и не проверяется.
Практическое правило: в первой версии оставляйте только те сценарии, без которых продукт не выполняет свою основную работу. Всё остальное — во вторую очередь, по факту обратной связи.
Что сильнее всего влияет на цену
Внутри одного уровня продукта цена может меняться заметно. Вот факторы, которые чаще всего её двигают.
- Число платформ. Нативная разработка под iOS и Android — две кодовые базы, два набора особенностей и две публикации. Кроссплатформенный подход сокращает объём, но не отменяет проверку на реальных устройствах.
- Авторизация и роли. Один пользователь — просто. Клиент, сотрудник, администратор, партнёр с ограниченным доступом — это уже модель прав, и её нужно проектировать, а не дописывать по ходу.
- Оплата. Онлайн-оплата требует не только кнопки: нужны сценарии возврата, повторной попытки, статусов заказа, сверки с провайдером.
- Офлайн-режим. Синхронизация данных при плохой связи — одна из самых дорогих частей проекта: конфликты версий, очередь отправки, поведение при дублях.
- Интеграции. Каждая внешняя система добавляет объём: согласование формата, тестовый контур, обработка недоступности, журнал обмена.
- Дизайн. Адаптация шаблона под фирменный стиль и индивидуальные макеты по каждому экрану — разные объёмы работ, и это видно в смете.
- Требования магазинов. Политики App Store и Google Play влияют на состав функций: например, правила внутренних покупок и обязательные экраны.
Отдельно стоит сказать про интеграции с учётными системами. Стоимость обмена зависит не от названия системы, а от задачи: какие данные, в какую сторону, как часто и кто считается источником истины. Подробный разбор порядка такой работы есть в статье про интеграцию сайта с CRM и 1С — логика для приложения та же.
Сроки: из чего они складываются
Срок — производная от объёма и от скорости согласований, а не от количества разработчиков. Удвоение команды не сокращает проект вдвое: часть времени уходит на коммуникацию и синхронизацию.
- Аналитика и согласование сценариев — самый недооценённый этап: здесь появляется список работ
- Дизайн и прототип — идут последовательно, правки после согласования дороже
- Разработка клиентской и серверной части — могут идти параллельно при готовом прототипе
- Интеграции и тестирование на реальных устройствах — зависят от доступов к внешним системам
- Публикация — проверка магазинов занимает время, которым мы не управляем
- Исправления после первых пользователей — планируйте их заранее, а не «если что»
Конкретные сроки по вашему проекту имеют смысл только после разбора задачи: до этого любая дата — обещание, а не план. В договоре фиксируются этапы и результат каждого этапа, чтобы движение было проверяемым.
Что обычно оплачивается отдельно
Аккуратная смета не прячет дополнительные статьи в «прочие расходы». Спросите прямо, что входит в цену, а что нет. Чаще всего отдельно идёт следующее.
- Аккаунты разработчика Apple и Google — оформляются на заказчика, оплата по тарифам магазинов
- Хостинг, домены и инфраструктура — по факту выбранной конфигурации, подробнее в разделе хостинг и серверы
- Индивидуальные макеты сверх согласованного объёма экранов
- Интеграции с внешними системами, которые не были в исходном списке
- Тексты, фото, иллюстрации, если их готовит не заказчик
- Поддержка и развитие после запуска: исправления, обновления под новые версии iOS и Android
- Продвижение приложения — отдельная работа, которая не входит в разработку
Эти пункты не «дополнительные поборы», а честная граница объёма: лучше увидеть их на этапе сметы, чем в счёте после запуска.
Как читать смету и что спросить до договора
Предложение на две страницы с одной итоговой цифрой почти всегда означает, что объём ещё не определён. Рабочая смета состоит из этапов, и по каждому понятно, что вы сможете проверить.
- Какие сценарии входят в первый релиз, а какие — нет
- Сколько экранов и какие состояния проработаны (пустое, ошибка, загрузка)
- Нативная разработка или кроссплатформа, и почему выбран этот вариант
- Что входит в серверную часть: какие данные, какие роли, какая админка
- Какие интеграции включены, а какие считаются отдельно
- Кто оформляет аккаунты магазинов и кто проходит проверку публикации
- Что происходит после запуска: гарантийный период, порядок доработок, кому принадлежит код
Последний пункт стоит выделить. Код, доступы и аккаунты должны принадлежать вам — это не формальность, а условие, без которого вы не сможете сменить подрядчика. Как проверять такие вещи заранее, разобрано в статье как выбрать подрядчика.
Как сократить бюджет без потери смысла
Экономия работает, когда уменьшает объём, а не качество. Вот что реально снижает стоимость и при этом не ломает продукт.
- Начать с одной платформы: сначала там, где ваша аудитория, вторую добавить после проверки сценариев
- Сократить число ролей в первой версии: часть операций может делать сотрудник в админке
- Отложить офлайн-режим, если сценарий допускает работу с интернетом
- Использовать готовые решения для оплаты и уведомлений вместо собственных реализаций
- Подготовить контент и описания заранее: ожидание материалов съедает сроки
- Не закладывать «на всякий случай» функции, которыми никто не будет пользоваться
Обратная сторона экономии — переделки. Переписывать навигацию или модель данных после запуска дороже, чем спроектировать их сразу: именно поэтому аналитика и прототип не тот этап, на котором стоит экономить.
Как получить оценку под свою задачу
Для точной оценки достаточно описать три вещи: кто пользуется приложением, какие действия он выполняет и с какими системами это связано. Дальше можно обсуждать состав первого релиза и порядок цен — без «уточним позже».
Если у вас уже есть описание или прототип, разбор займёт меньше времени: мы посмотрим сценарии, отметим риски и предложим, что войдёт в первую версию. Это не продажа «приложения вообще», а расчёт под конкретный результат — с составом работ и этапами.
Посмотрите также стартовые цены и состав работ и направление разработки приложений: там описано, что входит в базовый состав и какие форматы работ возможны.